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

Транзакция в попытке в попытке транзакции

транзакция
начало цикла
запись документа
конец цикла
фиксация транзакция

(2) ну это самый простой случай
бывают множественные вызовы чужих процедур и прочее

(3) ну может так

транзакция

попытка
исключение
конецпопытки


фиксация транзакция

(0) ошибка записи в попытке, и все это в транзакции

После ошибки записи транзакцию нужно отменять

(4) на самом деле там все сложнее, твой код может работать нормально а может нет...

ошибки генерятся разные и часть из них влияют на вышестоящую транзакцию а часть нет.


То есть тут нет все однозначно

(6) не правда.... точнее далеко не всегда...

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

(8) Привиди хоть один другой пример

запись/провдение/удаление - считаем за одно и тоже

(10) если в модуле обьекта при записи написать

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

верхняя транзакция нормально отработает

(10) если деление на ноль то можно не откатывать

(12) +

или так

ВызватьИсключение "парам"


то-же не влиет на верхнюю транзакцию

(12) ну это и есть ошибка при записи

(12) Хочешь сказать что один из документов не запишется, но транзакция при этом закоммитится?

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


транзакция

попытка
записьДокумента()
исключение
конецпопытки


фиксация транзакция

(9) надо чтобы начало/отмена транзакции  были в одной процедуре, ну и если начало транзакции внутри цикла, а отмена где-то еще, я бы не приветствовал.

(17) Ну если в транзакции только один этот документ записывается...
Но фиксация такой транзакции равносильна ее отмене

(18) что значит в одной?
К примеру есть процедура, которая сама по себе должна содержать транзакцию, чтобы была целостность записи.
Есть еще вторая процедура с такими же условиями, но она еще и вызывает первую.

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

(0) принципиальная ошибка делать так как советует (17)
делать нужно вот так https://its.1c.ru/db/metod8dev#content:2313:hdoc

а как вам такой типовой код?

СвояТранзакцияОткрыта = Ложь;
    
Попытка
    НачатьТранзакцию();
    СвояТранзакцияОткрыта = Истина;
    ...
    Если СвояТранзакцияОткрыта Тогда
        ЗафиксироватьТранзакцию();
    КонецЕсли;

Исключение
    Если СвояТранзакцияОткрыта Тогда
        ОтменитьТранзакцию();
    КонецЕсли;
    
КонецПопытки;

(23) в какой конфе эта дичь?

(23) Переменная Отказ в обработках записи, проведения и т.д. ведь не просто так используется. Зачем изобретать велосипед?

То есть вот такой код:

НаборЗаписей1.Записать();
НаборЗаписей2.Записать();

может дать такую ошибку
А вот такой:

Отказ = Ложь;
Попытка
   НаборЗаписей1.Записать();
Исключение
  Отказ = Истина;
КОнецПопытки;
Если Не Отказ Тогда
  Попытка
    НаборЗаписей2.Записать();
  Исключение
    Отказ = Истина;
  КонецПопытки;

такой ошибки не даст

(24) Управление торговлей, редакция 11.2 (11.2.3.84)

ну в УТ/ERP и счетчики на константах делали, так что я не удивлен

(26) первый код не может дать ошибку из (0)

(29) Да, немного не так

Попытка
  НаборЗаписи1.Записать();
Исключение
КонецПопытки;
Попытка
  НаборЗаписи2.Записать();
Исключение
КонецПопытки;

вот тут возможна такая ошибка

(30) всё равно в разных транзакциях

(22) Вы почитайте чего я писал выше по тексту...

в (17) я привел пример случая когда ошибка не оттранслированя с СУБД не приводит к отату верхней транзакции...

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

(26) В последних версиях платформы отказ (8.3) равносилен возврату и нет смысла проверять на отказ. Кстати, я в какой-то момент попался на этом.

(30) На самом деле методологи 1С за такое по шапке дадут, ибо по канонам записывать нужно вот так

Движения.Записать();

А у конкретных наборов объекта движений документа установить свойство Движения.НаборЗаписейЧегоТо.Записывать = Истина. А свойство записывать установлено в "Записывать модифицированные"

(17) Принципиальная ошибка. Вот тут

транзакция

попытка
записьДокумента()
исключение

Откат транзакции <- Обязательно

конецпопытки


фиксация транзакция

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

(34) Не факт. Например, в типовых БСП ошибки фиксируются записью в регистр. Выходом является установка заглушки через ДополнительныеСвойства

(35) Разумеется, написанное мною - это самый простой случай:) В хороших (универсальных) решениях, претендующих на роль библиотечных решений, должно быть больше возможностей для анализа. Вот тут неплохая статья на ИТС обо всем этом:

https://its.1c.ru/db/v8std#content:-2145783148:hdoc:_top:транзакция%20зафиксировать

(36) А ты повзрослел, прямо на моих глазах, хнык.
Ведь я тебя помню совсем юным,
v8: Вопрос по оптимизации
(1)

(37) Спасибо:) Я дорос до целого начальника:) И мистяне тут не на последнем месте.

(36) Метод хороший - тот, который предлагается в п. 3.6
Единственное, в Журнале регистрации будет зарегистрировано столько одинаковых ошибок, сколько было вложенных транзакций.