Мое почтение!

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

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

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

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

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

(4) багофича?

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

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

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

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

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

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

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

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

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

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

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

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

<Отказ>
Тип: Булево. Признак отказа от выполнения действия.

Факт в том, что установка отказа в отдельном обработчике не означает,
что это действие не будет выполнено.

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

(19) +1

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

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

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

Процедура ОбработчикКакогоТоСобытия(Отказ)
 Отказ=Истина;
 // какие-то действия
 Отказ=Ложь;
 //
 // Ай ай баги тупая платформа
КонецПроцедуры

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

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

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

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

Короче, пиши так и не парься :)

Процедура МойОчереднойГениальныйОбработчик(Отказ)
  Если Отказ Тогда
     Возврат;
  КонецЕсли:
...

(0) Если у тебя несколько обработчиков, надо писать так (и не парь мозг) -

Отказ = Отказ ИЛИ Истина;

или

Отказ = Отказ ИЛИ Ложь;

(29) Супер вообще...

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

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

(24) Еще каждый слушатель подписки надо предварять

Если Отказ Тогда Возврат КонецЕсли;

или

Если Не Отказ Тогда
// тело подписки

КонецЕсли;

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

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

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

Обратимся к книге П.С.Белоусова и А.В.Островерха "1С:Предприятие: от 8.0 к 8.1"

"При наступлении события, для которого определена подписка, выполняется такая последовательность действий:
  - обрабатывается событие в самом объекте ...;
  - если в процессе выполнения обработчика параметр Отказ установлен в значение Истина или вызвано исключение, последовательность действий прерывается;
  - в произвольном порядке вызываются внешние обработчики, назначенные для данного события;
  - ....;
  - если в процессе выполнения назначенного обработчика параметр Отказ установлен в значение Истина или вызвано исключение, последовательность действий прерывается;"

Т.е.
Подписки не будут выполнятся, если в основном обработчике Отказ = Истина.
Если Отказ = Ложь, будут выполнены все обработчики, назначенные в подписках. В каждом из них надо учитывать состояние Отказ.
Если это не понятно - кривые программы.

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

обходит твою ошибку, плюс позволяет пропустить уже ненужные проверки

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

Процедура ПодпискаНаСобытие1ПередЗаписью(Источник, Отказ) Экспорт
       Результат = Ложь;

       //далее куча анализа и присвоение "Результат" Истины или Ложь
       .....

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

Процедура ПодпискаНаСобытие2ПередЗаписью(Источник, Отказ) Экспорт
       Результат = Ложь;

       //далее куча анализа и присвоение "Результат" Истины или Ложь
       .....

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

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

(39) Это нормально, т.к. у нас ошибка, которую мы не можем обработать, и надо прервать выполнение...\

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

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

проверял на 8.2.14.537, сервер

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

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

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

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

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

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

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

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

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

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

(53) классный срач

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

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

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

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

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

(28)+100

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

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

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

(59) Зачем в форме то?

(61) Для отмены действия параметр "Отказ" придумали.

Сказ про белого бычка, на самом деле.

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

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

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

Пример "ПриОкончанииРедактированияТекста"

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

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

(61) - не надо, практика показывает, что установка отказа
в подписчике не гарантирует отмены действия.

(65) затем, что как в 28 - не меняет поведение.
Банальный практический пример это подтвердит.
Подписка на событие ПриЗаписи по регистру сведений.
Два подписчика.

Процедура ПодпискаНаСобытие1ПередЗаписью(Источник, Отказ, Замещение) Экспорт
   Сообщить("ПодпискаНаСобытие_1_ПередЗаписью");
   Отказ = Истина;
   Возврат;
КонецПроцедуры

Процедура ПодпискаНаСобытие2ПередЗаписью(Источник, Отказ, Замещение) Экспорт
   Сообщить("ПодпискаНаСобытие_2_ПередЗаписью");
   Отказ = Ложь;
   Возврат;
КонецПроцедуры

Проводим документ, выполняющий движения по РС.

Очередь вызовов:
ПодпискаНаСобытие_1_ПередЗаписью
ПодпискаНаСобытие_2_ПередЗаписью

результат - действие не отменено.
Если вызвать исключение в ПодпискаНаСобытие1ПередЗаписью - отменено.

(69) классный срач

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

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

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

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

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

(72) нет опечатки

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

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

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

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

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

(76) По моему, ты сам пытаешься это доказать.

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

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

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

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

Тим , "я тебе одну умную вещь скажу - ты только не обижайся"(с)

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

Процедура ПодпискаНаСобытие1ПередЗаписью(Источник, Отказ, Замещение) Экспорт
 Если Отказ Тогда
     Возврат;
  КонецЕсли;
  Отказ = Истина;
  Возврат;
КонецПроцедуры

Процедура ПодпискаНаСобытие2ПередЗаписью(Источник, Отказ, Замещение) Экспорт
 Если Отказ Тогда
     Возврат;
  КонецЕсли;
  Отказ = Ложь;
  Возврат;
КонецПроцедуры

(83) - Serg_1960, я прекрасно понимаю это внушение, я в 31 не зря указал: "ненадежно, если не исполняется стандартом кодирования".

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

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

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

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