Стек вызовов в инфологе в D365FO

[Damn]

Денис, заметил одну мелочь.
При использовании try catch retry инфолог ошибок внутри блока try catch удаляется с экрана пользователя. Но при этом попадает в журнал инфолога.
Хотелось бы и в журнале не видеть этот инфолог.

https://learn.microsoft.com/en-us/dy...try-statements
The retry statement erases all messages that have been written to the Infolog since program control entered the try block

[sukhanchik]

Цитата:

Сообщение от Damn

При использовании try catch retry инфолог ошибок внутри блока try catch удаляется с экрана пользователя. Но при этом попадает в журнал инфолога.
Хотелось бы и в журнале не видеть этот инфолог.

https://learn.microsoft.com/en-us/dy...try-statements
The retry statement erases all messages that have been written to the Infolog since program control entered the try block

Я не думаю, что это реально реализовать. Стек вызовов получается через штатную функцию xSession::xppCallStack и выдаётся в форму "как есть" без какого-либо анализа его содержимого.

Что происходит здесь:
1. Отрабатывает вывод сообщения (info / warning / error) внутри try.
2. При выводе сообщения срабатывает делегат по сохранению этого сообщения вместе со стеком вызовов (xSession::xppCallStack) в БД в специальную табличку.

Т.е. классно конечно, что

Цитата:

The retry statement erases all messages that have been written to the Infolog since program control entered the try block

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