Комментарии 8
В Конфигураторе же надо остановка по ошибке. Включили и ждем, пока упадёт. Зачем по шагам ходить было?
При хорошем стиле программирования так и должно быть. Но если у вас вложенные попытки - исключения, то остановка будет работать только при первой ошибке. В данном случае, запись в регистры была второй ошибкой, после какой-то незначительной ошибки, связанной толи с проверкой данных, толи еще с чем.
Проблема не во вложенных попытках как таковых. Проблема в том что транзакция испорчена. Не каждая ошибка в транзакции приведет к такому эффекту. Например, обращение к несуществующей процедуре в попытке не приведет к "протуханию" транзакции. А вот ошибки, связанные с обращением к данным - приведут, даже если исключение перехвачено.
В этом случае, любое следующее действие внутри транзакции приведет к "В данной транзакции уже происходили ошибки". Т.е. сама ошибка возникла ранее, но выстрелила в каком-то рандомном коде, который попытался выполнить действие в контексте протухшей транзакции.
Это делает дебаггинг этой ошибки одним из самых неприятных.
Полезно будет упомянуть, что на ИТС есть стандарт описывающий работу с транзакциями , рекомендую к ознакомлению.
В современном ЗУП 3.1 эта проблема решена.
Я однажды наблюдал со стороны модуль планирования на заводе, в котором была учтена посменная работа нескольких представителей (или выходцев) из двух противоборствующих банд. Их нельзя было в одном цеху ставить в одну смену, и выработку ихнюю нельзя было доверить другой банде. А вы тут про календарь какой-то, фу, нисмишнодаже.
Вы еще Озон с Вайлдберрис не парсили без официального API. Чувствуется, что я нанялся Шерлок Холмсом, а не программистом
Байки разработчика 1С: детективные