Логика обработки отказов - не ожидал...это описано в документации? #584016

Мое почтение! По причине того, что установка отказ=истина в обработчике подписки на событие передзаписью  не давала  ожидаемого эффекта - отказа действия, стал...думать, вот :) Стал пробовать. И обнаружил для себя  интересный эффект - оказывается, состояние отказа не проверяется платформой после вызова каждого обработчика - только после вызова всей очереди! О, как... Отсюда неприятненький эффект - в одном обработчике Отказ устанавливается в Истина, в последующем - в Ложь. И тогда состояние Отказа по логике первого обработчика уже не имеет никакого значения! Если последующий разрешил - будет исполнено. Эффект при незнании неприятный, вычислять по всем обработчикам корректность логики - та ещё радость. Собственно, из варинатов обхода приходит на ум либо использование исключения при необходимости гарантированного отказа, либо внутренняя клятва никогда, ни за что не использовать в обработчике события присвоение Отказу значения ложь... Хотя, имхо, было бы вернее всё-таки реагировать на состояния отказов по каждому огбработчику. ЗЫ: я в 1С 8 - чечако, для меня это так забавно и странно... а описания эффекта в доке не нахожу. Да и в сети - тоже. Есть ли официальная позиция по этому вопросу?

Может руки кривые?

Я сначало подумал стихи какие то=))

не использовать в обработчике события присвоение Отказу значения ложь

это не эффект, так и должно быть

багофича?

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

- фичебага звучит лояльнее к 1С

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

Причем тут баг?

- согласен, тот факт, что эта модель не есть зло, а есть особенность - признаю полностью.

+ Так и должно быть. Представьте почтальона, который, не смогши запихать письмо в один ящик, забивает (!) на разнесение остальные письма.

- я от наименования багом отказываюсь! :) И имхо тоже защищать не буду.

10 эта модель полностью отработает по всех подписка перед записью и если в конце будет отказ, то к при записи не перейдет. Более того, платформа не гарантирует порядок выполнения подписок.

короче. в умелых руках фича, в кривых все что угодно.

Вообще-то ПередЗаписью(<Отказ>... Т.е. если вы пришедшему значению Ложь присвоили значение Истина, то ССЗБ

- именно отсутствие предопределенной очереди исполнения, и приводит меня к моему имхо - реакция после каждого обработчика. Хотя где-то заявляют, что негласно очередь соответствует хронологии создания, могу уже из своей практики подвтердить - это не так. Созданный мною обработчик был последним, однако отказа не происходит, хотя код установки его значения исполняется.

Какой реакции? Ты понимаешь смысл параметра "Отказ"?

<Отказ> Тип: Булево. Признак отказа от выполнения действия. Факт в том, что установка отказа в отдельном обработчике не означает, что это действие не будет выполнено.

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

+1

- давай без экспрессии, дружище. Не гарантирует - о чем тут спорить? Мой предшественник, видимо, так поступал - а я пожинаю.

исключение выкинь :)

Окей, в твоем предшественнике. Но объяву дал ты, поэтому тебе и пожинать. Пойми ты, твоё недовольство совершенно аналогично следующему:

- пока так и сделал.

- не-не, совсем не аналогично. В условиях, когда очередь исполнения отдельных обработчиков не определена, такой примитивной линейности, как в примере, мы не имеем. Речь об общем случае. Недовольство платформой я вроде бы не заявлял.

А что обсуждаем? Руки оторвать.

Сначала ты: -Нет не пишем. А потом: -Ой, извини попутал, пишем

Короче, пиши так и не парься :) Процедура МойОчереднойГениальныйОбработчик(Отказ)   КонецЕсли: ...

Если у тебя несколько обработчиков, надо писать так (и не парь мозг) - Отказ = Отказ ИЛИ Истина; или Отказ = Отказ ИЛИ Ложь;

Супер вообще...

- ненадежно, если не исполняется стандартом кодирования. НЕт никаких гарантий, что после моего отказа не будет вызван обработчик, который не следует такой логике присвоения значения, а тупо определяет Отказ = Ложь. Подъём исключения надежнее, я думаю.

Улыбнуло:) Иногда лучше молчать, чем говорить (с)

Еще каждый слушатель подписки надо предварять Если Отказ Тогда Возврат КонецЕсли; или Если Не Отказ Тогда

бгг... может "И", а не "ИЛИ"

Отказ ИЛИ Ложь всегда даст значение Отказ Отказ И Ложь всегда даст значение Ложь Отказ ИЛИ Истина всегда даст значение Истина Отказ И Истина всегда даст значение Отказ

... или добавлять после изменения значения отказа "возврат" ...

Обратимся к книге П.С.Белоусова и А.В.Островерха "1С:Предприятие: от 8.0 к 8.1" "При наступлении события, для которого определена подписка, выполняется такая последовательность действий:   - обрабатывается событие в самом объекте ...;   - если в процессе выполнения обработчика параметр Отказ установлен в значение Истина или вызвано исключение, последовательность действий прерывается;   - в произвольном порядке вызываются внешние обработчики, назначенные для данного события;   - ....;   - если в процессе выполнения назначенного обработчика параметр Отказ установлен в значение Истина или вызвано исключение, последовательность действий прерывается;" Т.е. Подписки не будут выполнятся, если в основном обработчике Отказ = Истина. Если Отказ = Ложь, будут выполнены все обработчики, назначенные в подписках. В каждом из них надо учитывать состояние Отказ. Если это не понятно - кривые программы.

в уже ответили больше ничего и не требуется у себя делал также, когда на одно событие (перед записью документа) пришлось повесить несколько разных подписок обходит твою ошибку, плюс позволяет пропустить уже ненужные проверки

а писать Отказ = Ложь без проверки на отказ - это нормально?

Отказ = Отказ ИЛИ Результат; КонецПроцедуры    Отказ = Отказ ИЛИ Результат; КонецПроцедуры КонецПроцедуры

Конечно. Но если требуется выполнить все проверки, тогда .

Это нормально, т.к. у нас ошибка, которую мы не можем обработать, и надо прервать выполнение... а вот Отказ = Не Отказ -- это уже бомба (видел такое на практике, прог исходил из мысли, что Отказ -- первоналаьно всегда Истина)

только что проверил - сделал три подписки на одно событие (перед записью документа), во всех трех Отказ = Истина 1с зашла во все три процедуры, т.е. последовательность не прерывается! проверял на 8.2.14.537, сервер

как раз Отказ = Ложь указывает на отсутствие ошибки и без проверки на Отказ использовать - наживать кучу гемора

а почему последовательность должна прерваться?

+45 может есть действия , которые надо выполнить независимо от состояния отказа?

Я и написал - "будут выполнены все обработчики, назначенные в подписках. В каждом из них надо учитывать состояние Отказ."

А точно.... попутал немного с первой частью своего поста

да, возможно не так понял текст :)

+ Только при установке Отказ в Истина в основном обработчике происходит прерывание (не выполняются подписки).

установка Отказа не прерывает ничего

Прерывает последовательность вызова обработчиков.

(51, 52) - так это и было указано в первом же сообщении: значение отказа проверяется только после вызова всей очереди обработчиков. Никакие установки значения в обработчике, никакие возвраты не влияют автоматически на отработку всех подписчиков. Только исключение.

классный срач тебя сто раз объяснили, что в типовых нельзя ставить отказ=истина, а ты сто раз ответил что платформа херово документирована

При чем тут "исключение"?

вызов исключения в подписчике гарантированно отменяет действие.

Топором по серверу еще гарантированнее...

Все действия сразу, даже прошедшие

+100 Всегда следует вставлять этот код если в параметрах есть "Отказ", даже в обработчики формы :)

ты еще не пробовал вкус отката в бизнесс процессах, там вообще жесть :)

(57, 58) - почтенный, неуместная ирония. Логика такова, что действие должно быть отменено - и оно отменено, поскольку проверка - критическая; вполне транзакционное поведение.

Зачем в форме то?

Для отмены действия параметр "Отказ" придумали. Сказ про белого бычка, на самом деле.

в общем выражение "Отказ - Ложь;" должно быль немедленно выброшено, его применять не надо. Такая вот логика.

Если хочешь прервать выполнение обработчиков, пиши как . Зачем вызывать исключение?

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

А в каких случаях писать Отказ = Ложь имеет смысл?

(истерично) Ни в каких

- не надо, практика показывает, что установка отказа в подписчике не гарантирует отмены действия. затем, что как в 28 - не меняет поведение. Банальный практический пример это подтвердит. Подписка на событие ПриЗаписи по регистру сведений. Проводим документ, выполняющий движения по РС. Очередь вызовов: ПодпискаНаСобытие_1_ПередЗаписью ПодпискаНаСобытие_2_ПередЗаписью результат - действие не отменено. Если вызвать исключение в ПодпискаНаСобытие1ПередЗаписью - отменено.

классный срач тебя сто раз объяснили, что в типовых нельзя ставить отказ=истина, а ты сто раз ответил что платформа херово документирована

А подскажи - что это за событие такое "ПриОкончанииРедактированияТекста" - не припомню.

У тебя опечатка :) "true"->"false"

Ты нас разводишь чтоли?

Жесть. Ты хоть не позорься. В написано другое.

нет опечатки есть две беспредметные стороны спора

- уважаемый shuhard, я читал Твоё сообщение, просто не понимаю, что можно на него ответить. Я нигде не написал ничего о качестве документации, я лишь заметил, что не нахожу официального описания такого поведения, и спросил - где такое описание есть? И это было лишь однажды. (73, 74) - коллеги, не спорю. что другое. Я вам ответил - нужно ГАРАНТИРОВАННО отменить в обработчике действие. Ваши комментарии отностяся к каким-то иным сценариям; я привел код, который поясняет ситуацию. Но вы не отвечаете на фактуру, вы упорно доказываете, что я - м.дак.

ну просто выполняйте вашу подписку в самом конце, чего вы паритесь?

- сможете пояснить - в каком конце? Есть способ управлять очередностью выполнения подписчиков?

По моему, ты сам пытаешься это доказать. Какое поведение? Что после присваивания переменной в ней оказывается значение, которое присвоили? Это не описано? После Отказ=Ложь в переменной оказывается "ложь", ЭТО должно быть (так перетак) описано?

ну как они записаны в конфигурации - на 99% в таком порядке и выполняются. Остальной 1% проверите экспериментально.

Ладно, правильные ответы уже были даны в ,,,. Месите воду дальше ;)

я сам, похоже, на практике нарвался на негарантированный порядок - мой подписчик явно последний, однако он установкой отказа не отменяет действия. Кроме того, вроде бы, как упоминали в сети, сами разработчики официально предлагают считать порядок неопределенным.

При написании алгоритмов обработчиков нужно исходить из того, что они могут быть вызваны и порядок их вызова - неопределен. Поэтому, если надо  не потерять присвоение "Отказ = Истина;", то писать надо так (ваш пример сучетом п.28):

- Serg_1960, я прекрасно понимаю это внушение, я в 31 не зря указал: "ненадежно, если не исполняется стандартом кодирования". Это моя ситуация - не исполняется. Где-то кем-то написан обработчик, который не следует этому "хорошему" стандарту кода. Не мной. Конечно можно провести ревизию кода, найти преступную небрежность и убрать крамолу - и обязательно сделаем, и уже делаем. Но в условиях дефицита времени, полагаю, вызов исключение даёт мне совершенно удовлетворительный требуемый результат.

Ок, я вас услышал. Но - "не понял". В "условиях дефицита времени" не стоит писать индусский код - постоянный цейтнот вам гарантирован.

Благодарен всем за участие, знания и конструктивную полемику :)

Так пользуй кто не дает-то? 1С в УТ 11 вовсю использует исключения