Функция создания заказа была написана по стандартам разработки.
Упрощенный пример:
Функция СоздатьЗаказ(ВнешнийНомер)
НачатьТранзакцию();
Попытка
ДокументЗаказ = Документы.Заказы.СоздатьДокумент();
ДокументЗаказ.ВнешнийНомер = ВнешнийНомер;
ДокументЗаказ.Записать(РежимЗаписиДокумента.Проведение);
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
Возврат "Ошибка создания заказа";
КонецПопытки;
Возврат ДокументЗаказ.Номер;
КонецФункции
С очередным обновлением внутри документа заказа появилась доработка с ошибкой и одновременно написанная с нарушением стандарта разработки.
В модуле документа заказа.
Процедура ОбработкаПроведения()
....
//Последняя доработка в конце
Попытка
...запись в базу с ошибкой
Исключение
//по стандарту должно быть исключение, т.к. есть внешняя транзакция
//но его не было
//ВызватьИсключение;
КонецПопытки;
КонецПроцедуры
В результате, до обнаружения и исправления ошибки, довольно продолжительное время функция создания заказа успешно делал вид, что создает заказы и возвращала контрагентам какие-то номера.
В базе документы не появлялись.
На первый взгляд кажется, что функция создания заказа (она ведь по стандартам) рассчитана на ошибки внутри вложенных транзакций и на команде "ЗафиксироватьТранзакцию();" должна выдать до боли знакомое сообщение "В этой транзакции уже происходили ошибки!".
На практике функция возвращала номера как-будто создаваемых заказов!
Рассмотрим документацию на сайте "its.1c.ru".
В стандартах разработки в главе "Транзакции: правила использования (Новый раздел!)" почему то нет описания этого момента.
Ответ все-таки есть, но в разделе методической поддержки в главе "Вложенность транзакций".
Отрывок с сайта "its.1c.ru" (ссылка выше):
"При вызове отмены вложенной транзакции (явно или в результате произошедшего исключения) запоминается факт, что одна из вложенных транзакций была отменена (реального отката транзакции в этот момент не происходит), что приводит к невозможности фиксации результатов транзакции верхнего уровня. При этом, при попытке фиксации транзакции верхнего уровня никаких исключений выдано не будет. Просто вся транзакция завершится откатом. Соответственно, все изменения базы данных, произведенные в рамках транзакции верхнего уровня, будут отменены."
Вот и ответ, транзакция отменена, данные в базу не записаны, но это не вызывает исключения!!!
В свою очередь ошибка "В этой транзакции уже происходили ошибки!" возникает не на команде "ЗафискироватьТранзакцию();", а при первом обращении к базе (как при чтении, так и при записи) после отмены вложенной транзакции.
В нашем случае доработка была добавлена именно в конце модуля проведения, что в общем-то естественно, и обращений к базе больше не было.
Выводы и пожелания:
1. Хотелось бы в стандартах разработки на ИТС увидеть решение, более устойчивое к ошибкам в глубине стэка.
Например, перед командой "ЗафискироватьТранзакцию();" выполнять запрос к базе данных "Выбрать 1" для гарантированного вызова исключения "В этой транзакции уже происходили ошибки!".
Другой вариант это проверять, что ссылка "созданного" документа не пустая (ссылка объекта очищается при отмене транзакции).
2. Хотелось бы, чтобы когда-нибудь в будущем при отмене транзакции командой "ЗафискироватьТранзакцию();" вызывалось исключение.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Если ЗафиксироватьТранзакцию() станет выбрасывать исключение при установленном признаке отмены транзакции (сломанная транзакция), то придется во всех существующих конфигурациях в большом числе мест заменить ЗафиксироватьТранзакцию() на
т.к. далеко не все выбросы исключений станут полезными. А точнее большинство из них станут вредными, т.к. существующее поведение документировано и на него опирались программисты при написании кода. Определение функции ВТранзакцииПроисходилиОшибки() смотри в статье . В этой же статье показано, что метод ЗафиксироватьТранзакцию() при глубине = 1 не всегда фиксирует фактическую транзакцию, а закрывает ее путем отката если она сломана и путем фиксации если она не сломана. Поэтому правильнее было бы назвать его ЗакрытьТранзакцию(). А вот метод ОтменитьТранзакцию() имеет более правильное название, т.к. при глубине =1 всегда отменяет фактическую транзакцию.
(1)
Так то оно так. Но из статьи следует, что стандарт неустойчив по отношению к вложенным ошибкам. Что-то надо менять.
В текущей парадигме вложенность транзакций вообще не имеет смысла. Было бы логично увидеть это в стандарте, однако там опять какая-то лапша про вложенность, уровни и тп. Детский сад, вторая четверть…:( Какая может быть вложенность при том, что даже синхронный * не гарантируется ! Реально в транзакции может произойти одна ошибка и транзакция не будет откачена, хотя при второй откачена будет гарантированно (ну, с воплем «ошибки уже происходили»). В мануале же на эту тему опять какая-то лапша про уровни серьёзности ошибок…
зы прикольно, движок инфостарта считает слово ОТКАТ неприличным
(1) Вы правы, что поведение платформы лучше не менять и оставлять обратную совместимость.
Хорошая идея сделать новую команду.
(1)
У Вас шикарная статья, в том числе описывающая проблему, с которой я столкнулся.
Если Вы не против я подискутирую про приведенную выше цитату.
По моему мнению, если разработчик хочет отменить изменения он использует «ОтменитьТранзакцию();», а если потеря данных происходит в любом другом явно не указанном случае, то это ошибка, которую нельзя прятать и должно быть исключение.
(5) Я согласен, что если бы был правильный метод ЗафиксироватьТранзакциюОбязательно(), который бы выбрасывал исключение при установленном признаке отмены транзакции и о котором бы все знали, то во многих случаях разработчики применяли бы его для фиксации транзакции и это подняло бы качество кода.
Но менять логику работы уже используемого в огромном количестве кода метода слишком опасно, т.к. программисты могли как явно так и неявно опираться на эти нелогичные особенности его текущей реализации и тем самым обеспечивать корректную логику работы их программы.
В итоге я предлагаю использовать для борьбы со скрытой отменой/откатом транзакции собственный метод
Добавил его в статью в раздел «Скрытая отмена транзакции».
В платформе же я бы предложил добавить параметр «Обязательно» в метод ЗафиксироватьТранзакцию, при установке которого бы выбрасывалось исключение, а по умолчанию он естественно равен Ложь для обеспечения совместимости. Тогда наверное и не будет смысла его переименовывать.
ЗафиксироватьТранзакциюОбязательноВоЧтоБыТоНеСталоВоИмяБорис
У вас вообще с логикой проблемы, товарищ. После того как вы вываливаетесь в исключение, что вы пытаетесь вернуть далее? Номер какого документа?
Вот пример как делал недавно я:
Показать
Вот статья по работе с транзакциями: