Всем привет!

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

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

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

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

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

(4) нет

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

(2) ну вроде как да.

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

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

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

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

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

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

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

(13) хм.. логично

(14) почему потеряется?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(35) в чем плюсы?

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

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

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

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

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

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

(41) Читай (37)... И программируй :)
Если лень, то пиши через Исключение.
Если энтузиаст своего дела, то придумай свой велосипед :)

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

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

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

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

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

"не даст проводить "роботом"" - это что за зверь?

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

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

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

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

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

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

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

(50) Есть такие :)

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

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

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

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

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

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

- "Сообщить" в обработке проведения однозначно нельзя, так как ты находишься на сервере а метод клиентский;

- вызвать исключение тоже не камильфо: например при пакетном проведении документов (так сказать пачкой) мы остановим весь процесс;

Свой вариант :)))

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

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

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

А вообще да, абстракции такие абстракции)

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

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

(64)
Да, согласный.
>Доступность:
>Сервер, толстый клиент, внешнее соединение.

Но суть в том, что ошибки которые мы хотим Сообщить, покажутся на клиенте только после окончания серверного вызова.

Проверяется легко, обработка:
С клиента вызываем серверную процедуру и в цикле выводим сообщения.

Нет смысла выводить сообщение сразу: лучше сформировать стек, сгруппировать сообщения, потом вывести.

В этом плане, ИМХО, подход в бухе 7.7 (кажется) был самым правильным (после попытки провести отчет с результатом)...

PS Все написанное мое личное мнение и может отличаться и других :)

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

(63) Есть есть транзакция, то используется Отказ, если код выполняестся вне транзации - ВызватьИсключение.

На ИТС есть статья по этому поводу (Система стандартов и методик разработки):
http://its.1c.ru/db/v8std#content:2149184049:hdoc:_top:вызватьисключение

+ к (64)

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

Вообще, надо смотреть, что там за сообщение в проведение. Кажется мне, что вместо "ОбработкаПроверкиЗаполнения" используется "ОбработкаПроведения".

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

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

(69) Как все запущено...

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

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

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

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

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

77+ Прошу прощения по поводу перед записью

Возникает перед выполнением записи элемента справочника. Процедура-обработчик вызывается после начала транзакции записи, но до начала записи элемента справочника.

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

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

Но отмена например могла бы быть и результатом выполнения.
Например вместо

Попытка
    Объект.Записать();
Исключение
    Предупреждение("Не удалось записать объект """ + Объект + """!
                   |" + ОписаниеОшибки(), 60);
КонецПопытки;


Если не Объект.Записать() Тогда
действия

Данные об ошибки можно передавать в ДополнительныеСвойства

(79) Читай 78.

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

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

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

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

(84) При чем тут это?

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

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

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

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

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

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

(90) Кхе-кхе:

v8: СКД. Вывод поля через точку в Настройках. Как убрать префикс?
v8: 1С 8.2. Как сделать таблицу в поле запроса "вручную".
v8: 1С 8.2 УФ. Событие НаКлиенте после отмены проведения.

А ведь этим темам не больше года.

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

(91) И что не так в этих темах? Ты уверен, что знаешь все? Уверен, что документация раскрывает все возможные проблемы? Я, например, не уверен.

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

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

(92) Я уверен, что Вам объективно рано делать заявления, подобные (83) :)

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

Через эту штуку удобно делать всякие аудиторские записи, инкременты счетчиков за т.д - это да.

А за алгоритм вида "делаем построчный update, где не сделался - пропускаем" любой опытный ораклоид сперва оторвет Вам руки, а затем понесет директору служебку о Вашем несоответствии занимаемой должности :)

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

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

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

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

(97) https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/autonotransaction_pragma.htm - особенно много внимания уделяем разделу "Usage Notes" - про пересечения блокировок, дедлокам с вложенными транзакциями и т.д.

(98) Это зависит от того, что говорит собеседник. И как аргументирует свою точку зрения.

100

(99) Это понятно. Где там про "А про вложенные транзакции - это ведь просто обертка над вторым коннектом к БД."

(101) О господи... Вы вообще способны анализировать информацию?

Если что-то выглядит как другая транзакция, на вкус как другая транзакция, пахнет как другая транзакция, то это - бинго - другая транзакция.

Чего еще Вам надо? :)

(102) прекрасное применение бритвы окама коллега))

(102) Т.е. разницу между словами "коннект" и "контекст" вы не улавливаете? На постгре "автономная транзакция" действительно реализована с помощью поднятия второго подключения. И это действительно негативно сказывается на производительности. В то время как в Oracle в рамках той же сессии создается новый контекст. В итоге Оракловый вариант работает не в пример быстрее костыля у постгри.

(102) " то это - бинго - другая транзакция" Кто спорит?

(104) Ок, сам напросился. Какие именно операции работают не в пример быстрее?)

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

(107) Подключение - это логическая сущность, она ничего не стоит. Также как, например, сеанс в 1С.
Открытие транзакции также операция бесплатная.

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

Какие из этих операций и в каких случаях будут выполняться быстрее благодаря описываемому Вами неху от оракла?)

(108) Т.е. поднять еще одно соединение к БД ничего не стоит? 0_о Вот это да. Особенно забавно поднимать это соединение в рамках одной транзакции.

(109) У вас каша в головке. Это транзакции подчиненны соединениям, а не наоборот. И да, теперь хочу от Вас два ответа:

1. Чего же такого стоит поднять соединение к БД?
2. Какие операции чтения и записи в таблицы и индексы при использовании оракловой вундервафли будут выполняться быстрее и за счет чего?

Вы окажете мне честь и дадите развернутые ответы?

(110) "Какие операции чтения и записи в таблицы и индексы при использовании оракловой вундервафли будут выполняться быстрее и за счет чего? " Это вы придумали.

(110) "1. Чего же такого стоит поднять соединение к БД? " Время?

(110) "Это транзакции подчиненны соединениям, а не наоборот." Блин. Ну вот вам ближайшая ссылка по постгре и ее "автономным транзакциям": http://habrahabr.ru/post/99645/

(111) Тогда чем же эта штука быстрее, черт возьми?

(112) Время выполнения 99% запросов сильно больше времени установки tcp-соединения. Что за чушь Вы втюхиваете?

(112) Не увидел по Вашей ссылке соединений, подчиненных транзакциям.

(9) ОБщегоНнзначения.СообщитьОБошибке

(96) В 7.7 ил 8? В 7.7 прясые запросы несколько оправдывают, а вот в 8 - только недоумение.

*прямые

(115) В 8. Еще б я в 2014 году 7.7 обсуждал

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

(113) "Не увидел по Вашей ссылке соединений, подчиненных транзакциям." В транзакции вызывается функция log, которая использует dblink_exec, поднимающее новое соединение к базе, в котором выполняется требуемая "вложенная" транзакция. Кстати, про подчинение соединения транзакции вы написали.

задавался похожим вопросом
v8: Чем плоха ВызватьИсключение ?

только так

(113) "Время выполнения 99% запросов сильно больше времени установки tcp-соединения. Что за чушь Вы втюхиваете? " Пропустил примечательный момент. Т.е. вы не видите ничего плохого в запросах в цикле? :) Ведь именно это и происходит в реализации с помощью костыля в постгре.

(0)А зачем вообще "ВызватьИсключение"?

+(122)

(118) Риски - вы полностью "обходите" всю бизнес-логику, заложенную вендором. Судя по описанию Вашего отдела - Вам срочно нужно принять в свой отдел фиксина - Вам его очень не хватает.

>> Функция log, которая использует dblink_exec,
>> поднимающее новое соединение к базе, в котором
>> выполняется требуемая "вложенная" транзакция.

Эта "вложенная" транзакция не имеет никакого отношения к исходной. И к ее соединению тоже.
И про подчинение соединений транзакциям я не писал, покажите номер сообщения.

(121) Запросы в цикле плохи не переустановкой соединений (которых за счет пула вообще не будет), а многократным обращениям к таблицам и индексам для получения данных, которые могут быть получены за одно обращение к таблицам и индексам.
И да, при любом групповом перепроведении будут запросы (update, insert) в цикле - почему-то за все время существования 1С от этого никто не умер.

(124) "Риски - вы полностью "обходите" всю бизнес-логику, заложенную вендором." Давай конкретно, какую логику мы обходим заполняя новый реквизит (число, булево,ссылка, неважно) в сотнях тысяч и миллионах старых объектов?

"И про подчинение соединений транзакциям я не писал, покажите номер сообщения." смотри (110),(113). Вы придумали "подчинение соединения транзакции" и требовали от меня это показать.  Хитро :-)

(124) "И да, при любом групповом перепроведении будут запросы (update, insert) в цикле - почему-то за все время существования 1С от этого никто не умер." А есть выбор?

(124) "а многократным обращениям к таблицам и индексам для получения данных, которые могут быть получены за одно обращение к таблицам и индексам. " Хм, это да. Интересно, Оракловая плюшка оптимизирует этот момент или нет? Надо спросить у наших ораклистов...

(125) >> Какую логику мы обходим

1. Механика денормализации в платформе (таблицы остатков для регистров и т.д.)
2. Авторегистрация изменений для планов обменов и отложенной регистрации (последнее особенно забавно выглядит)
3. Обработчики событий

>> Вы придумали и требовали

Ты про это написал в (109)

(126) Выбор есть всегда

(127) Конечно. А еще кофе вариант, а минет админу делает. Это ж Оракл)

+(128) Отложенной реструктуризации, а не регистрации

(128) 1. Мы тут про реквизит объекта: справочник, документ. Хотя и регистр сведений приходилось, но там достаточно обновить итоги для обновления таблицы среза последних.

2. Вы и вправду думаете, что есть желание регистрировать изменения в миллионе старых объектов для обмена?0_о Типа, пусть все другие системы удивятся :-)

(128) 3. Угу. Обработчиков событий нам не хватало в этой ситуации. Круто получть спам на миллион доков в ящик по рассылке :-)

(129) Как думаете, эти обработки в какой момент выполняются?

(128)"Ты про это написал в (109)" Нет.

"Конечно. А еще кофе вариант, а минет админу делает. Это ж Оракл)" Как минимум может использоваться общий кэш в рамках сессии.

(130) (131) Если в вашей базе перезаписать милллион объектов - будет миллион писем? Мне жаль вашего работодателя.

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

А для отложенной реструктуризации никаких обработчиков нет - это механизм платформы. С ней у Вас все должно получиться при выполняющейся отложенной реструктуризации - свои таблички вы поправили, а платформа потом мило их удалит и заменит на содержимое *NG.

(132) Мечтаю увидеть кэш таблицы регистра бухгалтерии от большой базы. Как работает СУБД вы не понимаете, это я уже понял. Прекратите попытки понтовать ораклом, у Вас не получается.

(133) "А вообще все это уже решено штатными средствами (и необходимость регистрации, и управление необходимостью выполнения обработчиков событий) - см. типовые." О, опять вы придумали проблему, а потом начинаете говорить, что это все решается. Я в курсе, как это реализуется платформой. Прямой апдейт мы делаем не для этого. Это вы сказали про эти механизмы, как источники проблем, не я.

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

"Мечтаю увидеть кэш таблицы регистра бухгалтерии от большой базы." Сколько уже можно все извращать? Сначала придумали соединения, подчиненные транакциям, потом придумали волшебное чтение/запись в Оракл. Жесть. И требуете отвечать за ваши фантазии.