Уважаемые специалисты, посоветуйте пожалуйста, как правильно в КА2 исправить появление вот такой ошибки:

Добавленный в КА2 2.4.5.86 документ при проведении делает следующее (документ не мой, делали до меня):

Вызывается процедура в которой происходит запись в РС примерно так:

    НачатьТранзакцию();
    
    Попытка
        НаборЗаписей.Записать(Ложь);
    Исключение
        ОбщегоНазначенияКлиентСервер.СообщитьПользователю("У сотрудника " + ДанныеФизическогоЛица.ФизическоеЛицо + "уже существует ЛС по зарплатному проекту " + ДанныеФизическогоЛица.ЗарплатныйПроект);
    КонецПопытки;

    ЗафиксироватьТранзакцию();

При выполнении ОбщегоНазначенияКлиентСервер.СообщитьПользователю() появляется ошибка. Я погуглил и решил отказать от транзакции вообще (т.к. проведение уже вызывает транзакцию) - не помогло. Попробовал делать транзакцию как советует ИТС:

        НачатьТранзакцию();
        
        Попытка
            
            НаборЗаписей.Записать(Ложь);
            ЗафиксироватьТранзакцию();
            
        Исключение
            
            ОтменитьТранзакцию();
            ОбщегоНазначенияКлиентСервер.СообщитьПользователю("У сотрудника " + ДанныеФизическогоЛица.ФизическоеЛицо + "уже существует ЛС по зарплатному проекту " + ДанныеФизическогоЛица.ЗарплатныйПроект);
            
        КонецПопытки;


тоже не помогло.

Увидел в интернете, что корень зла в том, что во всём виновата обработка исключения сделал вот так:

        ЕстьОшибка = Истина;
        Попытка
            
            НаборЗаписей.Записать(Ложь);
            ЕстьОшибка = Ложь;
            
        Исключение
        КонецПопытки;
        
        Если ЕстьОшибка Тогда
            ОбщегоНазначенияКлиентСервер.СообщитьПользователю("У сотрудника " + ДанныеФизическогоЛица.ФизическоеЛицо + "уже существует ЛС по зарплатному проекту " + ДанныеФизическогоЛица.ЗарплатныйПроект);
        КонецЕсли;


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

(30) Некоторые не заморачиваются

+(31) еще сверху попытка и пустое исключение.

(31) Оно в любом случае все будет отменено, что в этот пирог попало, но _не при первом минусовании счетчика_

(27) я не делал никаких выводов, я знаю как правильно.
Но поправлять такое приходится за другими постоянно.

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

(35) А почему на (21) наезжаешь? Из-за нарушения парности "плюс" и "минус"?

(37) Потому что ТранзакцияАктивна() нельзя верить

(36) писюны не то слово, ну да ладно

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

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

(41) Потому что при (40) ты получишь: Исключительная ситуация — Транзакция не активна.

А я вот никому не доверяю, ибо случаи были)

(42) Это получит тот кто выше по стеку попытается зафиксировать/откатить, когда счетчик уже выведен в ноль кодом товарища из (21) - Я в этом только косяк вижу того цикла.

(44) Забей.

Разбирайся с транзакциями и убирай лишние вложенные

(44) Я просто год назад наткнулся на то, что это работало не совсем так как должно, кейс уже не помню, но горело знатно.
По этому я больше не верю ТранзакцияАктивна() )

Попробовал воспроизвести - сейчас все работает как надо.
Возможно была какая то ошибка платформы.

(22) друзья, но ведь мы уже в исключении, не имеет уже значения сколько было тразнакций до нас, и сколько выкинуто других исключений, ничего уже зафиксировать не получится, поэтому если нам нужно гарантировано в коде продолжить успешное выполнение операции - нужно всё откатить, и если нужно - опять начать транзакцию заново. Да, есть стандарт 1с, который гласит - заворачивайте всё всё в попытку с откатом, но если раззуть глаза - то становится понятно, это хорошо до тех пор, пока кто-то забыл так сделать и вот тогда - опять "ошибки в транзакции"

(49) +1. И полностью согласен.
Но я точно помню что этот кусок кода не работал как надо((( Возможно я не очень везучий(
Пока ТранзакцияАктивна() Цикл
  ОтменитьТранзакцию();
КонецЦикла;

(0) для начала читаем здесь:
https://habr.com/post/419715/
а в продолжение - реализуем корректную обработку на всех уровнях вложенности транзакций

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

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

(49) "пока кто-то забыл так сделать"
кто-то это кто?

(53) "даже если код по стеку и пойдет, это уже бесполезно, ни одна транзакция не будет зафиксирована"
По стеку не обязательно нужно идти чтобы зафиксировать транзакцию.

(53) Парность надо соблюсти чтобы тот код, что по стеку выше и соблюдающий парность, не споткнулся из-за того, что ты всю парность убил в предлагаемом цикле. Хз с чего ты взял о каком-то успешном завершении транзакции.

(56) Опять 25. У вас есть код, который начинает транзакцию и фиксирует ее, парность сохранена, все счастливы? Далее, возникает исключение между начать/зафиксировать, так вот, если что-то по стеку ниже перехватывает исключения, то уже не нужно извините "дрочиться" с парностью, все, поздно, пока не размотаем транзакции, ничего более сделать не получится. Ведь начать (и не отменить/зафиксировать) транзакцию могли сто раз в коде функций между первым начать/зафиксировать. И стандарт спешит на помощь: предлагает там, где есть начать/зафиксировать используйте попытку, чтобы сделать откат. Вот я и говорю - работать такое будет до тех пор, пока кто-то забудет так сделать...и вот ради чего, парности? Если ваш код обрабатывает объекты в транзакции, и вам нужно продолжать выполнение этого кода, если возникает исключение, то вы не можете полагаться на то, что до вас, все транзакции отменили в правильной последовательности. Вы же не считаете, что соблюдая супер- парность, транзакция3 позволит вам зафиксировать изменения, в случае возникновения исключения во вложенной в неё транзакции4? Давайте пример кода и хватит демагогии.

(57)
> пока не размотаем транзакции, ничего более сделать не получится.
Стандарт не предлагает здесь и сейчас размотать транзакции и продолжить работу, а предлагает эскалировать исключение на верхние вызовы путем выполнения ВызватьИсключение. Т.к. часть записей в БД на верних вызовах уже не будет закомичена, и эти верхние уровни должны об этом знать.

> Давайте пример кода и хватит демагогии
Примера кода есть в типовых, в частности я привел в (19)
А вот что предлагаешь ты разматывая транзакции здесь и сейчас и продолжая работу?

(58) "Стандарт не предлагает здесь и сейчас размотать транзакции и продолжить работу"

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

"А вот что предлагаешь ты разматывая транзакции здесь и сейчас и продолжая работу?"
Я утверждаю, что все белиберда с п.3.6. Почему?
1) Да потому что достаточно в 1 из 100500 мест не сделать так, как велит стандарт (коих тьма тьмущая в типовых), и мы получаем проблему, с которой начался этот топик.
2) Никого не смущает, что в попытку нужно завернуть порядочное количество кода, что уже противоречит другому стандарту? И не завернуть его нельзя, по стандарту 3.6
Ну и самое главное, снова повторю, единственно правильным считаю класть в попытку не все подряд, что начинается с НачатьТранзакцию (твой 3.6 так говорит), а использовать попытку только там, где это нужно с точки зрения прикладной задачи, а в исключении этой попытки - не надеяться, что все другие начать/отменить/зафиксировать были сделаны в порядке вызовов, а самому всё откатить и продолжить работу, начав новую транзакцию или что там по задаче требуется. И не нужно думать ни о какой парности при возникновении ислючения, что за параноя на этот счет, если в 999999ой НачатьТранзакцию выбросилось исключение, вы уже никакими ОткатитьТранзакцию/ЗафиксироватьТранзакцию данные не сохраните в 999998 и т.д. транзакции.

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

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

Так ты приведи свой код, а не очередные рассуждения.

Это к (59)

(57) "У вас есть код, который начинает транзакцию и фиксирует ее, парность сохранена, все счастливы? Далее" // Конечно же неправильно. У меня есть код, который фиксацию транзакции и значимую часть оной делает внутри попытки, а откат - в искючении.

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

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

(0) Проблема в том, что слишком часто используется Попытка Исключение КонецПопытки;
В большинстве случаев проверки на корректность и т.п. можно и нужно делать другими способами.
А Попытку-Исключение можно использовать в тех случаях, когда выполняются какие-то действия, где проверку средствами платформы проблематично сделать. Например, при записи/чтении файла, когда нет уверенности в наличие прав, или при создании COM-объекта и т.п.

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

(59) так будет пример кода с разматыванием транзакций, например, для такого случая:

1 НачатьТранзакцию()
2 Объект1.Записать()
3    НачатьТранзакцию()
5    Объект2.Записать()
4    Объект3.Записать() - случилась ошибка при записи

Как нужно поступить после строки 4?

(68) Один раз вызвать исключение

(68) в твоем примере нет перехвата исключения, поэтому ошибки "в этой транзакции уже были ошибки" не будет, поэтому вопрос я не понял.
Но попробую. Какую проблему мы обсуждаем? Мы обсуждаем вот что: как правильно перехватывать ошибки любого рода, хоть деление на 0, которые происходят в транзакции. Верно?
То есть мы говорим не о НачатьТранзакцию в принципе, а тех, совершенно конкретных участках кода, где нам очень-очень нужно что-то обрабатывать (в цикле проводить доки, например) и делать это в транзакции. Так? Не знаю как тебе, но я говорю именно о таких случаях. Ну и вот, в этих участках кода, на следующей строке после "Попытка" мы запускаем какой-то код, который понаоткрывает транзакций, и который в общем случае их за собой не закроет (и не должен!). И в этом конкретном участке кода, следующей строкой по "Исключение", учитывая тот факт, что транзакции вложенными быть не могут, нужно отмотать все, и заново начать транзакцию, если это что-то в цикле, или отменить, в зависимости от задачи.
Возвращаясь к вопросу "Как нужно поступить после строки 4?" - никак, будет исключение, все отменится и все будет хорошо.

А теперь вишинка: если мы четвертую строку обернем в попытку и там будет исключение, то что бы мы не делали, Обеъект2.Записать () - в базе не появится! При том, что метод ЗафиксироватьТранзакцию () в какой-нибудь 5 или 6 строке отработает. Поэтому я в очередной раз утверждаю, что цикл размотки транзакций (см. 21) самый практичный подход.

(68) После строки 4 уже никак не поступить. Ибо выполнение кода прервано по ошибке. ЗафиксироватьТранзакцию() не сыграло

(70) > Мы обсуждаем вот что: как правильно перехватывать ошибки любого рода, хоть деление на 0, которые происходят в транзакции. Верно?
Нет не верно. Перехват деления на ноль не будет провоцировать ошибку "В транзакции уже происходили.." и можно будет зафиксировать транзакцию.

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

и причем здесь проведение документов в цикле? не вижу, что об этом был разговор

ты так и не привел пример программного кода
покажи кодом что ты будешь делать в примере (68)

Я понял автора (70) - он про случаи, когда надо "и рыбку съесть, и костями не подавиться" :) Т.е. когда идет пакетная транзакция и из-за ошибки записи одного из объектов не хочется отлуп всем остальным в пакете делать.

если код не в глобальной транзакции то делать надо так

   Попытка
   НачатьТранзакцию();
    
        НаборЗаписей.Записать(Ложь);

    ЗафиксироватьТранзакцию();

    Исключение
если транзакцияактивна() тогда отменитьтранзакцию() конецесли;
        ОбщегоНазначенияКлиентСервер.СообщитьПользователю("У сотрудника " + ДанныеФизическогоЛица.ФизическоеЛицо + "уже существует ЛС по зарплатному проекту " + ДанныеФизическогоЛица.ЗарплатныйПроект);
    КонецПопытки;

(73) > и костями не подавиться
это в лучшем случае

(65) > Вызывать исключения наверх тоже не всегда хорошо
кстати не обязательно вызывать исключение
можно просто протаскивать флаг ошибки через функции
тот же пресловутый "Отказ"

(76) "можно просто протаскивать флаг ошибки через функции"
Знать бы еще сколько таких флагов на каждом уровне вложенности иметь нужно...

+ (77) В "классике" ошибка должна быть обработана на том уровне, где она возникла. А на верх должен передаваться результат выполнения.

(78) а если ошибка критичная, которая прервала транзакцию?

(0)Не делать вложенности попыток
.Эти заразы самый нижний кетч считают себе исключением...ВСЕ высшие Попытка будут закрыты одним нижним Исключене..

(78) Я конечно понимаю, что у 1С свое понятие об инкапсуляции. Но все же. Вызывая функцию из вашей библиотеки я не должен знать что и как у вас там внутри устроено. Я должен знать только за успешное/не успешное выполнение. Описалово проблемы в случае неуспешного вызова вложенной функции должно идти бонусом. И все исключения вложенного уровня должны быть там же и обработаны. Поскольку в общем случае я могу и не знать как обрабатывать ваши исключения.

(81)>>что у 1С свое понятие об инкапсуляции

Поподробнее об инкапсуляции в 1с можно?:)

(81)Жаль конечно, но 1С тебе ничего не должна:-)

(81)Ну так что там у нас инкапсулируется в 1С?  Или ты просто пи@бол?

(82) Ну... Допустим объекты ИнтернетПочта.

(85) ХА. Три раза

(84) Ой... Ты не знал за инкапсулированные объекты в 1с? Ну типа ИнтернетСоединение или там... DOM?

(87)Это хрень, которую интерфейсами 1С дает :
-))

(86) Ага. Кроме таких аргументов нет?
"Или ты просто пи@бол?" ЦЫ из (64)?

Это точно не инкапсуляция:-)

(88) Ага. То есть за инкапсуляцию понятие = "0"... Пичаль.

(89)Инкапсуляция, это если я могу сделать свой класс...

Как минимум

И в этот класс инкапсулировать свои процедуры

твк что я как одинесник хотел бы этого, но...

Не судьба

(92) "если я могу сделать свой класс."
А если ты пользуешься чужими классами с закрытой реализацией то это что?

(97)Чужая реализация - это чужие команды. Учить можно но не очень приятно

(94) "И в этот класс инкапсулировать свои процедуры"

Я не знаю как это называется в ваших этих интернетах... Но как только я могу модифицировать класс своими  свойствами и/или методами - в наших интернетах это называется полиморфимзм.

(99)ну ка дай определение Полиморфизм?

(98) ГЫ. "Учить можно но не очень приятно"
Реализация класса в большинстве случаев закрыта. И "Учить" ты можешь только вызов публичных методов. И не можешь "учить" вызовы приватных.
Ну да бог с ним...

не гугли..Быстродавай:-)

(100) Поищи в своих интернетах. Там должно было быть.

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

Пиписки одинаковые... можно убирать

:-)

(105)У него в программинге вообще пипски нет.

(107) Ну все. Ты конечно первый переТц. Хоть и не в курсе за инкапсуляцию. Ну то такое...

(108)Я даже знаю что такое инкапсуляция. Но тебе не скажу.Сам учись:-)

(109) Когда для объекта ДокументDOM выкатишь реализацию метода ВставитьПеред() - продолжим. А пока (с учетом (98)) - ты то что прописано в (84).

>>реализацию метода ВставитьПеред()
Это как раз наследование:-)

Ну продолжай...

(111) Реализация = наследование? Такого я еще не слышал...
Впечатление такое, что на форуме бот с произвольной генерацией текста...

(113)>> Реализация = наследование
Да запросто.

Мне интересны твои доводы против:-)

(114) Я уже не удивляюсь.

(116)Естественно.Ты идешь паситсь:-))

Пастись и есть траву:-))

(117) А кроме хамства еще какие-нибудь аргументы есть?

(119)У меня тоесть.А у тебя нет.

кто пустил детей в интернеты

(121)Они там живут(дети),сволочи..

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

Все что я смог по этому поводу, уже написал, повторяю: пример кода был в 21, а твой случай 68 - ничего там делать не нужно, поэтому примера кода нет.

Учись юзать ВызватьИсключение

(123) понимаешь в чем дело, в 1с нет стека транзакций и флаг отката транзакции он глобальный, то есть без разнице на каком уровне произошла ошибка ты не сможешь откатить или зафиксировать одну транзакию внутри другой.

по этому код в (21) это банально мусор...

теперь объясняю почему 74 правильно:
запись документа - это не явная транзакция и если в ней происходит ошибка то она взводит глобальный флаг ошибкитранзакции, и по этому если в ней произошла ошибка надо явным образом откатить транзакцию верхнего уровня,  или вообще не надо делать верхнюю транзакцию

кстати, кто там говорил что в типовых не ипользуется эскалация исключения (ВызватьИсключение;)
посмотрите ут11 - на каждом шагу

(126) Всему должно быть место и время.
То, что исключение должно быть обработано на своем уровне изоляции - это да.
Но вот такой пример. Из моей практики. Обращение к ВЕБ-Сервису с передачей некорректных параметров. Теоретически возможно проанализировать параметры, обработать и вернуть допустим код ошибки. Вроде все правильно. НО. В таком варианте ошибка самого ВЕБ-сервиса будет неотличима от ошибки на вызывающей стороне. Потому в модуле ВЕБ-сервиса вызывается такая вот фигня :
ВызватьИсключение "Трам пам пам";

И тогда ошибка вызывающей стороны диагностированная в ВЕБ-сервиса вызовет исключение не у себя в модуле, а передаст выше по стеку вызовов.

+ (127) А по поводу транзакций - вот здесь https://its.1c.ru/db/metod8dev#content:2313:hdoc все от "создателя".

(128) тут вопросов нет

(127) чет не понял, что ты сказать хотел

(130) Насчет кидать исключения наверх или нет.
1. Стараться не кидать.
2. Смотреть по обстоятельствам.