Показать сообщение отдельно
Старый 26.10.2023, 13:53   #8  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,275 / 3476 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от 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() какой-нибудь триггер по очистке стека вызовов - неправильно, ибо основная суть стека вызовов и состоит в том, что когда уже все сообщения потёрлись - он остался
__________________
Возможно сделать все. Вопрос времени