Отказ = Истина или ВызватьИсключение? #726668

Всем привет! Как Вы думаете, что правильнее писать, например, в ОбработкаПроведения, если документ проводить нельзя?

Всем привет! Как Вы думаете, что правильнее писать, например, в ОбработкаПроведения, если документ проводить нельзя?

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

а что, если нельзя, то это сразу исключение?

только не "сообщить", а конечно должно быть Предупреждение. )

А разве ВызватьИсключение не к Попытка-Исключение относится?

нет

нет. иногда удобно открывать незапущенный конфигуратор ;)

ну вроде как да.

Посмотреть в типовых и поступать, как специалисты. Им там виднее.

Эммм... Особенно это круто выглядит в транзакции на несколько документов...

, все равно мне кажется - это неправильно.

В типовых первый вариант.

да нормально ;) Если к=40 Тогда   ВызватьИсключение "Нельзя делить на 40!"

Исключение это обработка исключительной ситуации, когда выполнение кода может завершиться ошибкой исполнения. Это как микроскопом гвозди забивать, вам не кажется?

Вот мое мнение, интересно, что Вы думаете: при использовании первого варианта могут возникнуть ситуации, когда мы не сможем узнать о причине того, что документ не проведен, например, при создании документа из модуля веб-сервиса. В этом случае причина, которую мы бы выводили в Сообщить("Док. не проведен по причине...") просто потеряется. А если использовать второй вариант мы всегда можем поднять сообщение об ошибке на нужный уровень и правильно его обработать.

хм.. логично

почему потеряется?

а я когда-то в логи выводил все сообщить. потом утром читал

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

+ а то что мы выводим в Сообщить просто канет хз куда.

Исключение выгодно использовать ,когда ошибку надо реально обработать. Например, необходимо внести информацию по ошибке и контексту в таблицу и по окончании процесса вывести ее пользователю.

Если документ проводить нельзя, то сообщение должно быть в обработке проверки заполнения, а не в обработке проведения. Ошибки (которые прерывают транзакцию) должны сообщаться путем ВызватьИсключение. Чтобы система правильно все понимала и, например, в журнале регистрации отразила

Созданные, но не выведенные пользователю можно собрать через ПолучитьСообщенияПользователю

У ВызватьИсключение есть очень большой минус для групповой обработки - ломает транзакцию. Вместо того, чтобы записать/обработать 100500 элементов одной транзакцией приходится без нее в этом случае делать.

ну то есть я правильно понимаю: вы тоже считаете, что Отказ лучше не использовать?

все зависит от случая ... мне больше нравится. Хотя я уверен что это не правильно (Есть такое мнение что все что мне нравится не правильно)

я считаю, что об исключительных ситуациях надо сообщать путем ВызватьИсключение

в одной транзакции нужно обрабатывать только те данные в верность которых ты уверен на 1000 процентов.

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

Скажите, а для чего, как Вам кажется, нужна транзакция?

Целостность данных, конечно же. Но как побочный результат, можно слегка оптимизировать работу с БД.

Отказ = Истина; тоже генерирует исключение, только описание ошибки будет совсем не информативное: "Ошибка при вызове метода контекста (Записать): Операция не выполнена!"

модальные вызовы в транзакции. за такое руки отрубают вместе с головой.

Как напишешь, то и получаешь :)

Судя по приставке "Когда-то", ты перестал заниматься пустым :)

Пиши свои ошибки в Доп.Свойство Объекта, потом анализируй. Все в твоих руках, если они есть :)

в чем плюсы?

Что плюсы? Судя по вопросам, "Ты хочешь и Рыбку съесть и на стуле посидеть". Ты программист или Дворник? "Будь мужиком, напиши свой обработчик ошибок!"  :)

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

+ Ошибка "Не заполнен реквизит <Реквизит № 1>" Может быть всего лишь верхушкой Айзберга. А ошибок может быть куева туча. ... Но а ты со своим Исключением получишь только одну, да и то мало внятную, если напишешь в ошибку весь талмуд всех ошибок :)

Объект в любом случае создается на сервере 1С :) А кто дал команду, это уже дело пятое :)

при использовании вариант 1 я и одной ошибки не получаю.

Вызвать исключение тебе потом не даст проводить "роботом", будешь искать где же это я накосячил.

Читай ... И программируй :) Если лень, то пиши через Исключение. Если энтузиаст своего дела, то придумай свой велосипед :) ... Предлагаю написать по человечески в зависимости от потребности детализации ошибка на стороне Веб-Клиента :)

Так какая в опу может быть целостность данных, если одна из операций не выполнена?

Какое в опу нарушение целостности ,когда не обновлен/создан один из 100500 несвязанных элементов? А нагрузка на БД, если делать одной транзакцией будет меньше и отработает шустрее.

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

связанные они или нет - неважно. к транзакционным системам есть требование атомарности, то есть или все изменения прошли, или ни одно.

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

Т.е. ты все-таки не знаешь, для чего нужны транзакции?

С учетом того, сколько времени отнимает встроенный язык, трансляция запросов и т.д. - кто-то правда задрачивает на оверхед от транзакционной машины в СУБД?

Отказ это не анахронизм, это именно тот параметр который предназначен для этой ситуации

чем хуже второй вариант (про его выгоды читаем 14)?

Есть запись в журнал регистрации. Опять же во многих случаях желательно проверить все ветки алгоритма. Вызов исключения приостанавливает выполнение.

Отказ = Истина это то же самое исключение.

Есть такие :)

+ "Вызов исключения приостанавливает выполнение" - смотря как его обрабатывать.

Конечно, это уже поставка от 1С, т.е. если документ не провелся, то получи исключение. Все нормально и логично. Я бы сказал ожидаемо :)

Если доступен флаг Отказ, то стараюсь нужно использовать его. Для случаев, когда Отказ недоступен можно использовать ВызватьИсключение. + установка Отказ в Истина не прерывает исполнения процедуры/функции.

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

Отказ отработает поле завершения процедуры. Отказ можно установить в Истина, но не прерывать выполнения процедуры, например выполнить все проверки и сразу сообщить об их результатах пользователю, а не выдавать сообщения по частям.

Господи, дай мозгов этим людям

- "Сообщить" в обработке проведения однозначно нельзя, так как ты находишься на сервере а метод клиентский; - вызвать исключение тоже не камильфо: например при пакетном проведении документов (так сказать пачкой) мы остановим весь процесс;

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

можно, метод не только клиентский.

Сообщить вполне себе есть на сервере. Даже при вызове из фонового задания вполне работает. Даже то, что было запихано в Сообщить внутри фонового задания потом прочитать можно. А вообще да, абстракции такие абстракции)

+ Отказ = Истина при выходе из ОбработкаПроведения точно так же все остановит, потому что Отказ = Истина это тоже генерация исключения.

Если ты обрабатываешь исключение, то это просто перевод (goto) кода в обработчик исключение Отказ это не исключение это ОтменитьТранзакцию

Да, согласный. >Доступность: >Сервер, толстый клиент, внешнее соединение. Но суть в том, что ошибки которые мы хотим Сообщить, покажутся на клиенте только после окончания серверного вызова. Проверяется легко, обработка: С клиента вызываем серверную процедуру и в цикле выводим сообщения. Нет смысла выводить сообщение сразу: лучше сформировать стек, сгруппировать сообщения, потом вывести. В этом плане, ИМХО, подход в бухе 7.7 (кажется) был самым правильным (после попытки провести отчет с результатом)... PS Все написанное мое личное мнение и может отличаться и других :)

10-25% процентов экономии порой. Не ахти-что, но иногда экономит лишние полчаса-час. Конечно, надо учитывать блокировки. А кто-то предлагает бездумно что-то использовать?

Есть есть транзакция, то используется Отказ, если код выполняестся вне транзации - ВызватьИсключение. На ИТС есть статья по этому поводу (Система стандартов и методик разработки):

Если еще немного порассуждать, использование СообщениеПользователю в ОбработкеПроведения не дает возможности привязать сообщение к элементам формы (прилипалки в 8.3)... Вообще, надо смотреть, что там за сообщение в проведение. Кажется мне, что вместо "ОбработкаПроверкиЗаполнения" используется "ОбработкаПроведения".

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

нет подписки, не можешь основные тезисы сюда скопипастить?

Как все запущено... Если такой любитель наслаждаться сайд-эффектами - найди в коде все вызовы Новый БлокирвокаДанных и закомментируй. Тоже немало производительности выиграешь.

"А кто-то предлагает бездумно что-то использовать?"

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

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

77+ Прошу прощения по поводу перед записью Возникает перед выполнением записи элемента справочника. Процедура-обработчик вызывается после начала транзакции записи, но до начала записи элемента справочника. да флаг отмена вызывает отмену транзакции и исключение по выходе из процедуры.

"Вообще то передЗаписью выполняется вне Транзакции" ПередЗаписью модуля объекта выполняется уже в транзакции Здравая мысль про запись в журнал регистрации (1-й вариант не пишет, 2-й пишет), это я как то упустил. Но все равно думаю это не очень существенно.

Но отмена например могла бы быть и результатом выполнения. Исключение     Предупреждение("Не удалось записать объект """ + Объект + """! действия Данные об ошибки можно передавать в ДополнительныеСвойства Читай 78.

И во втором не будет писать если явно отключить запись ошибок в ЖР

Молча посочувствую твоему работодателю

Ожидаемо. Мир чуть больше, чем тебе кажется.

Правда думаешь, что я никогда на T-SQL ничего не разрабатывал? :D

При чем тут это?

Это к вопросу осознания ширины мироздания быдлокодерами на встроенном языке без названия)

Т.е. ты считаешь, что никогда и ни в коем случае, нельзя лезть в 1С прямыми запросами? И что же случится при этом? Мир рухнет, сатана вылезет из ада, солнце потухнет?

Тебе - точно не стоит)

Есть еще один минус исключений. Иногда невозможно полностью оттестить все ветки алгоритма, и например проведение записи документа ставишь в обработчик исключений. Записываешь в ЖР, а пользователю сообщаешь что бы обратился к программисту. То есть нужно еще разделять пользовательские исключения и исключения системы. В нормальных языках это регулируется классом ошибок. Обычно при проведении интересно узнать все возможные причины отказа проведения, а не останавливаться на первой попавшейся.

смелое заявление. Обоснуй.

Кхе-кхе: А ведь этим темам не больше года. Диагноз: 1. "Мальчик паталогически не переносит учебу" - т.е. на лицо банальная аллергия на на чтение документации 2. При этом самомнение - как у вчерашнего девственника, оценивающего свой сексуальный опыт 3. Первое и второе вместе - я бы тебе даже доступа в рабочую базу не дал.

И что не так в этих темах? Ты уверен, что знаешь все? Уверен, что документация раскрывает все возможные проблемы? Я, например, не уверен. А самомнение только у тебя. Т.к. твое представление о работе с транзакциями кажется единственно верным. А бедные быдлокодеры из шаражки Oracle напридумывали и используют такую ересь, как автономные транзакции. Не понимают своей ущербности :(

Кстати, по мотивам ,а тебе самому не показалось странным и нелогичным, что есть клиентское событие ПередЗаписью, серверное ПередЗаписьюНаСервере, но нет клиентского ПослеЗаписи? Мне вот показалось. Но у меня нет такого самомнения, чтобы быть уверенным в безвыходности этой ситуации :(

Я уверен, что Вам объективно рано делать заявления, подобные :) А про вложенные транзакции - это ведь просто обертка над вторым коннектом к БД. Ваша "вложенная транзакция" не разделяет блокировок основной и т.д. И, что самое главное - описываемого Вами "ускорения" операций в транзакции Вы уже не получите - с таким же успехом, можете просто запускать фоновое задание в коде на встроенном языке и дожидаться его завершения из кода, выполняемого в транзакции - будет тоже самое. Через эту штуку удобно делать всякие аудиторские записи, инкременты счетчиков за т.д - это да. А за алгоритм вида "делаем построчный update, где не сделался - пропускаем" любой опытный ораклоид сперва оторвет Вам руки, а затем понесет директору служебку о Вашем несоответствии занимаемой должности :)

"Я уверен, что Вам объективно рано делать заявления, подобные " Т.е. Вы считаете ,что видели все и знаете обо всем? Печально, жить скучно, должно быть.

Я видел достаточно, чтобы гордые рассказы об ускорении обработки за счет транзакций и прямые запросы к 1Сной базе вызывали у меня только facepalm. Остальное - Ваши домыслы .

"А про вложенные транзакции - это ведь просто обертка над вторым коннектом к БД." Вы это с постгрёй не путаете?..

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