Добавить опцию к экшену "Не выполнять BadGoodEnd"

[Meteorburn]

Добавить опцию к экшену после которого не выполнять BadGoodEnd.

Допустим это важно при принудительном критическом завершении шаблона, где не нужно использовать действия из BadGoodEnd.

 

[Phoenix78]

Я системой меток пользуюсь. в goodend свич стоит который разветвляет выполнение в зависимости от того в какой части шаба завершилось.
с BadEnd также. но там всегда свич всего на 1-2 ветвления, как правило.

 

[Meteorburn]

Я системой меток пользуюсь. в goodend свич стоит который разветвляет выполнение в зависимости от того в какой части шаба завершилось.
с BadEnd также. но там всегда свич всего на 1-2 ветвления, как правило.

Поэтому и предлагаю ввести такую опцию, чтобы было проще и не создавать доп. действий со статусами / метками.

 

[Konrod_m]

Я системой меток пользуюсь. в goodend свич стоит который разветвляет выполнение в зависимости от того в какой части шаба завершилось.
с BadEnd также. но там всегда свич всего на 1-2 ветвления, как правило.

а можете пример привести какой-нибудь действий от свитча? типа гуд энд - варианты "закончилось норм" и "и завершили с грандиозным феерическим успехом"? и что можно вести от бедэнда тоже не совсем понятно - кроме стандартных ошибок..

 

[doc]

по хорошему изначально нужно было несколько гибче делать эту штуку с бэдэндом при принудительном прерывании выполнения. Если бы просто был еще один кружок наравне с bad_end и good_end, не знаю, что-то типа abort_end, от которого можно было бы провести стрелку. Хочешь - веди к тем же кубикам, куда ведет bad_end, а хочешь - не используй вовсе. Намного гибче могло бы быть

 

[Meteorburn]

а можете пример привести какой-нибудь действий от свитча? типа гуд энд - варианты "закончилось норм" и "и завершили с грандиозным феерическим успехом"? и что можно вести от бедэнда тоже не совсем понятно - кроме стандартных ошибок..

Например есть шаблон парсер и условно он разделён на две части.
Одна часть это проверка файлов, проверка лицензии и другие второстепенные действия.
И есть основная часть: сбор данных. Так вот в сборе данных при любой ошибке (включая не предвиденные) или успешном завершении нужно сохранить данные. В этом случае применяется GoodBadEnd.

Так вот при ошибке на этапе проверки файлов, выполнять GoodBadEnd не нужно, потому что сохранять ещё нечего. А так как GoodBadEnd в шаблоне присутствует, то он пойдёт его выполнять.

Понятно, что можно прописать логику, где будет проверяться есть ли результаты и просто не выполнять сохранение. Но тогда может быть такой случай, что парсинг был, а результатов не было и GoodBadEnd не будет выполняться, но при этом нужно вывести оповещение, что результатов не нашлось. В таком же случае будет это оповещение выводиться, даже если была ошибка на этапе проверки файлов. То есть нужно ещё 100500 кубиков или кода написать для проверки условий. Куда проще если бы это сразу завернули в опцию не выполнять GoodBadEnd после конкретного действия.

Касательно также других шаблонов, где есть действие после которого нужно принудительно завершить шаблон без выполнения GoodBadEnd. Например, в шаблоне в GoodBadEnd выполняется смена IP у прокси. Допустим при проверке почты для верифа перед регой, почта оказалась не валидная. Мне в таком случае не нужно выполнять лишнее действие для смены IP, я просто хочу принудительно завершить шаблон.

по хорошему изначально нужно было несколько гибче делать эту штуку с бэдэндом при принудительном прерывании выполнения. Если бы просто был еще один кружок наравне с bad_end и good_end, не знаю, что-то типа abort_end, от которого можно было бы провести стрелку. Хочешь - веди к тем же кубикам, куда ведет bad_end, а хочешь - не используй вовсе. Намного гибче могло бы быть

С abort_end вот хорошая идея.

 

[Meteorburn]

del

 

[Konrod_m]

Например есть шаблон парсер и условно он разделён на две части.

Теперь понятно о чем речь. Поддерживаю

 

[Phoenix78]

а можете пример привести какой-нибудь действий от свитча? типа гуд энд - варианты "закончилось норм" и "и завершили с грандиозным феерическим успехом"? и что можно вести от бедэнда тоже не совсем понятно - кроме стандартных ошибок..

ну на BadEND у меня развилка висит на сохранение лога, данных критических, какой то возврат в списки. это типа плановый плохой выход ну когда я не ставлю метку особую. В этом месте я вообще не обращаюсь к браузеру, так как неизвестно почему мы здесь в данный момент. Может таймаут сработал и поток был принудительно закрыт или браузер завис. Ничто не должно мешать выходу. Но на период активной отладки я ставлю метку-разрешения на запись отладочной инфы, DOM, source, скрин.
по GOOGEND выше написали причины развилок. У себя делаю обработку ошибок в самом шаблоне и например было определено, что данные для продолжения работы шаблона отсутствуют. и сделать ничего нельзя кроме как завершения работы, но не вызывать же ошибку что бы не идти на GOOGEND поэтому я знаю, что надо сделать в GOOGEND именно в этой ситуации и ставлю метку "1" и спокойно даю завершится логике. если возникнет подобная ситуация дальше по ходу работы шаблона и тоже нужен непредвиденно-запланированный выход то метка "2" и на выход. Стандарт выхода это метка "0".
Не вижу разницы, если я щас ставлю один дополнительный кубик с меткой, там где мне это нужно, или же разработчики сделают галочку в кубиках, которая будет сигнализировать непонятно о чем, все равно придется открывать этот крайний кубик и проставлять эту настройку.
Потом, ну вот сделан например шаблон, большой, хороший, работающий со многими данными.... и вот такая ситуация, мы проставили вот эти настройки, которые при прерывании шаблона не идут на BadGoodEnd, другими словами не отрабатывается сохранение важных данных. И вот пользователь, ну такой среднестатический юзер, прерывает работу шаблона принудительно, а у нас не отрабатывает сохранение данных.... что прилетит вам в личку ? (что то типа, ля.... куда пропал мой самый любимый аккаунт для спама ? ) А зачем это нам ? Ну вот таких мест в шаблоне когда не надо отрабатывать сохранение данных раз-два и обчелся, никаких проблем прям щас проставить там установку метки с нужным кодом, а в GOOGEND добавить ветку на этот код, по которой ничего не делается. Ну разве я не прав ?