Смотрите последние 15, 16, 17 и 18

Удалил исходное чтобы не путать.... Не, там не интересно))) Там все логично и ожидаемо.

с другой стороны ПередЗаписью в форме на клиенте происходит за пределами транзакции записи как это указано на ИТС, так что все согласно документации. Разработчик должен сам решать должно ли исключение влиять на запись и похоже оборачивать Попыткой и ставить Отказ=Истина, если нужно.

Могу еще рассказать как положить дженкинс в докере и отправить весь сервис докера в дикий затуп (а иногда и весь хост в оффлайн), просто запустив на слейв-агента на хосте. Знаю как, но не знаю почему))
Запуск агента не по 127.0.0.1:8080, а по MyHostName:8080 + /etc/hosts » "127.0.0.1 MyHostName".
И все... Блэкаут.
(Имя MyHostName прописано в дженкинсе как корневой урл)
Остановил слейв (на нем заданий не было) - все проснулось. Запустил слейв через IP - все работает норм.
Почему так нельзя было делать?))

Ну и что, что транзакции нет?
Предлагаете теперь каждую процедуру нужно оборачивать в попытку? Или при входе в каждую процедуру проверять не упала ли предыдущая? )))

Любое поведение должно быть ожидаемым и обосновано логикой. Вне зависимости от возможностей обхода или допустимых костылей.
Если поведение не логично - оно должно быть приведено в норму. Или нормальные программисты перейдут на другой язык)

Это баг! Так не должно быть. От слова НИКОГДА,

Более того на платформе  (8.3.15.1958) - этого поведения и нет.

Если в коде (до транзакции ошибка) - то транзакция и стартовать не должна.

А у них получается - гдето стоит "Попытка Исключение" над всеми обрабочтиками клиента.
Которая эти исключения глотает ))

Сильное заявление. Уточнять его у разработчиков платформы мы конечно не будем

Это предположение.

Т.е. они скажут, что "ну так сделано" и все будет хорошо? ))))))))))))))))))))))
Нужно конечно, но не уточнаять, а сообщить об ошибке.
Ошибка - потому что это не логично, не ожидаемо, и просто потому что поведение - ппц.

А то что исключение не останавливает код что это если не баг?

На партнерке вполне могут ответить "Поведение не задокументировано" и, следовательно, какие предъявы? :)
Но скорее всего конечно же признают багом.

Добро пожаловать в АСИНХ

Вообще поведение кода в 1с ожидаемое везде.
При необработанном исключении исполнение прерывается полностью.
Вне зависимости транзакция это или нет

Ничо против не имею.
Но если это последовательность событий следующих одно за другим. - то какой такой Асинх?

Тот АСИНХ, которого мы заслужили ))))

в релизной 18й ошибка остается

Грусть. Запланирован переход на неё...

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

Господи, что вы тут развели. Эта "ошибка" есть начиная с 8.3.9.
Во-первых, исключения вне транзакции записи элемента используются только для прерывания проверок конкретного обработчика событий, о чем сказано в стандарте
https://its.1c.ru/db/v8std#content:499:hdoc (п. 3.5)

Все нормальные люди в основном работают с параметром Отказ.
И если бы уважаемые программисты читали Радченко, то увидели бы замечательную схему обработчиков событий:
https://i.imgur.com/ERBmZsi.png

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