Работа с параметром «Отказ» в обработчиках событий
1. В обработчиках событий модулей объектов, наборов записей, форм и т.п., содержащих параметр Отказ (ПриЗаписи, ОбработкаПроверкиЗаполнения, ТоварыПередНачаломДобавления и т.п.), не следует присваивать этому параметру значение Ложь.
Это требование обусловлено тем, что, как правило, в коде обработчиков событий параметр Отказ может устанавливаться сразу в нескольких последовательных проверках (или в нескольких подписках на одно и то же событие). В таком случае к моменту выполнения очередной проверки параметр Отказ уже может заранее содержать значение Истина, и можно ошибочно сбросить его обратно в Ложь.
Кроме того, при доработках конфигурации на внедрении число этих проверок может увеличиться.
2. Эти же требования справедливы для других аналогичных параметров обработчиков событий: СтандартнаяОбработка, Выполнение и др.
Например:
Другие материалы по теме:
Нас находят: 1с как работает отказ, как в процедурах используется параметр отказ, ОбработкаПроверкиЗаполнения(Отказ ПроверяемыеРеквизиты)
Работа с параметром «Отказ» в обработчиках событий
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. В обработчиках событий модулей объектов, наборов записей, форм и т.п., содержащих параметр Отказ ( ПриЗаписи , ОбработкаПроверкиЗаполнения , ТоварыПередНачаломДобавления и т.п.), не следует присваивать этому параметру значение Ложь .
Это требование обусловлено тем, что, как правило, в коде обработчиков событий параметр Отказ может устанавливаться сразу в нескольких последовательных проверках (или в нескольких подписках на одно и то же событие). В таком случае к моменту выполнения очередной проверки параметр Отказ уже может заранее содержать значение Истина , и можно ошибочно сбросить его обратно в Ложь .
Кроме того, при доработках конфигурации на внедрении число этих проверок может увеличиться.
2. Эти же требования справедливы для других аналогичных параметров обработчиков событий: СтандартнаяОбработка , Выполнение и др.
Например:
3. Неприемлемо в событиях объекта ПриЗаписи , ПередЗаписью , ПередУдалением , ОбработкаПроведения , ОбработкаПроверкиЗаполнения и т.п устанавливать параметр Отказ в значение Истина без информирования пользователя о причинах:
В таких случаях сообщение об ошибке не информативно и скрывает истинные причины проблемы, поэтому расследование ошибки требует значительных временных затрат:
Не удалось записать «Заказ покупателя»!
Следует согласно пп. 1.1 и 1.3 стандарта Информирование пользователя корректно уведомить пользователя о причинах отказа с помощью сообщения или вызова исключения.
Отказ истина 1с что это
ПередЗаписью (BeforeWrite)
Синтаксис:
ПередЗаписью(<Отказ>, <ПараметрыЗаписи>)
Параметры:
2 комментария:
Сейчас столкнулся с такой задачей, решение в голову пришло такое же. Но есть одна проблема: мы не можем отследить нажал пользователь кнопку "Провести и закрыть" или просто "Провести". Можно, конечно, не закрывать, но у пользователей сразу возникнет большое количество вопросов: "Почему я нажал "Закрыть", но ничего не закрылось".
Отказ = Истина или ВызватьИсключение?
Как Вы думаете, что правильнее писать, например, в ОбработкаПроведения, если документ проводить нельзя?
(41) Читай (37). И программируй 🙂
Если лень, то пиши через Исключение.
Если энтузиаст своего дела, то придумай свой велосипед 🙂
.
Предлагаю написать по человечески в зависимости от потребности детализации ошибка на стороне Веб-Клиента 🙂
"не даст проводить "роботом"" — это что за зверь?
"будешь искать где же это я накосячил" — я и искал, пока у меня не было нормальных сообщений об ошибках, потом сразу стало гораздо легче.
— "Сообщить" в обработке проведения однозначно нельзя, так как ты находишься на сервере а метод клиентский;
— вызвать исключение тоже не камильфо: например при пакетном проведении документов (так сказать пачкой) мы остановим весь процесс;
(62) Сообщить вполне себе есть на сервере. Даже при вызове из фонового задания вполне работает. Даже то, что было запихано в Сообщить внутри фонового задания потом прочитать можно.
А вообще да, абстракции такие абстракции)
(64)
Да, согласный.
>Доступность:
>Сервер, толстый клиент, внешнее соединение.
Но суть в том, что ошибки которые мы хотим Сообщить, покажутся на клиенте только после окончания серверного вызова.
Проверяется легко, обработка:
С клиента вызываем серверную процедуру и в цикле выводим сообщения.
Нет смысла выводить сообщение сразу: лучше сформировать стек, сгруппировать сообщения, потом вывести.
В этом плане, ИМХО, подход в бухе 7.7 (кажется) был самым правильным (после попытки провести отчет с результатом).
PS Все написанное мое личное мнение и может отличаться и других 🙂
(63) Есть есть транзакция, то используется Отказ, если код выполняестся вне транзации — ВызватьИсключение.
Если еще немного порассуждать, использование СообщениеПользователю в ОбработкеПроведения не дает возможности привязать сообщение к элементам формы (прилипалки в 8.3).
Вообще, надо смотреть, что там за сообщение в проведение. Кажется мне, что вместо "ОбработкаПроверкиЗаполнения" используется "ОбработкаПроведения".
(69) Как все запущено.
Если такой любитель наслаждаться сайд-эффектами — найди в коде все вызовы Новый БлокирвокаДанных и закомментируй. Тоже немало производительности выиграешь.
(72) Вообще то передЗаписью выполняется вне Транзакции.
Но это не суть. Смысл Отказа это установка флага ошибки.
Которое внутри процедуры не прекращает ход выполнения.
Но обрабатывается при выходе из предопределенной процедуры.
А дальше уже может вызываться исключение, Отмена Транзакции.
Просто по смылу отказ ближе к ОтменаТранзакциию
Смысл исключения перед отменой именно в немедленном прекращении процедуры с записью ошибки в журнал регистрации и вывода исключения для пользователя
Исключения которые перехватываются внутри процедуры это просто оператор перехода в обработчик исключения.
77+ Прошу прощения по поводу перед записью
Возникает перед выполнением записи элемента справочника. Процедура-обработчик вызывается после начала транзакции записи, но до начала записи элемента справочника.
да флаг отмена вызывает отмену транзакции и исключение по выходе из процедуры.
Но отмена например могла бы быть и результатом выполнения.
Например вместо
Попытка
Объект.Записать();
Исключение
Предупреждение("Не удалось записать объект """ + Объект + """!
|" + ОписаниеОшибки(), 60);
КонецПопытки;
Если не Объект.Записать() Тогда
действия
Данные об ошибки можно передавать в ДополнительныеСвойства
(79) Есть еще один минус исключений. Иногда невозможно полностью оттестить все ветки алгоритма, и например проведение записи документа ставишь в обработчик исключений.
Записываешь в ЖР, а пользователю сообщаешь что бы обратился к программисту.
То есть нужно еще разделять пользовательские исключения и исключения системы. В нормальных языках это регулируется классом ошибок.
Обычно при проведении интересно узнать все возможные причины отказа проведения, а не останавливаться на первой попавшейся.
А ведь этим темам не больше года.
Диагноз:
1. "Мальчик паталогически не переносит учебу" — т.е. на лицо банальная аллергия на на чтение документации
2. При этом самомнение — как у вчерашнего девственника, оценивающего свой сексуальный опыт
3. Первое и второе вместе — я бы тебе даже доступа в рабочую базу не дал.
(91) И что не так в этих темах? Ты уверен, что знаешь все? Уверен, что документация раскрывает все возможные проблемы? Я, например, не уверен.
А самомнение только у тебя. Т.к. твое представление о работе с транзакциями кажется единственно верным. А бедные быдлокодеры из шаражки Oracle напридумывали и используют такую ересь, как автономные транзакции. Не понимают своей ущербности 🙁
(92) Я уверен, что Вам объективно рано делать заявления, подобные (83) 🙂
А про вложенные транзакции — это ведь просто обертка над вторым коннектом к БД. Ваша "вложенная транзакция" не разделяет блокировок основной и т.д. И, что самое главное — описываемого Вами "ускорения" операций в транзакции Вы уже не получите — с таким же успехом, можете просто запускать фоновое задание в коде на встроенном языке и дожидаться его завершения из кода, выполняемого в транзакции — будет тоже самое.
Через эту штуку удобно делать всякие аудиторские записи, инкременты счетчиков за т.д — это да.
А за алгоритм вида "делаем построчный update, где не сделался — пропускаем" любой опытный ораклоид сперва оторвет Вам руки, а затем понесет директору служебку о Вашем несоответствии занимаемой должности 🙂