OberonCore
https://forum.oberoncore.ru/

#044 Поведение Kernel.SetTrapGuard
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6704		 Страница 1 из 1
Автор:  Иван Денисов [ Понедельник, 04 Январь, 2021 17:50 ]
Заголовок сообщения:  #044 Поведение Kernel.SetTrapGuard
Есть в ядре процедура, которая позволяет отключить вывод дампов во время аварийных остановок.
С наличием Services.SafeAction это позволяет делать интересные варианты для обработки исключений.
Однако полного отключения не происходит, срабатывает диалог для обработки по-умолчанию.
В Linux — это вывод сообщений в консоль, а вот в Windows версии ошибки всплывают в виде диалоговых окон.

Цитата:
PROCEDURE SetTrapGuard (on: BOOLEAN)
TRUE отключает показ окна дампа в случае исключения.


Как вы смотрите на то, чтобы SetTrapGuard полностью отключал вывод дампов? В целом примерно так и ожидается согласно имеющейся благодаря усилиям Ильи Ермакова и Александра Ильина документации.
Автор:  adimetrius [ Вторник, 05 Январь, 2021 13:46 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
Странно, что в Вин предъявляется окно.

В ядре Линукс я предпринимал специальные усилия, чтобы отчет выводился в консоль всегда, это не дефолтное поведение.

Окно, конечно, не следует предъявлять пользователю, если SetTrapGuard(FALSE). А в консоль я бы оставил вывод - это в любом случае не для пользователя, а для системного программиста. И вот почему: одно из самых отвратительных явлений - это "замалчивание" ошибки: что-то пошло не так, но программа вида не подает. В этой ситуации принудительный вывод в консоль, который виден только системному программисту, который специально запустил ББ из консоли, чтобы видеть сообщения - спасителен. Это неоднократно сохраняло мне массу времени, когда что-то шло не так в оконной или текстовой подсистеме, или мало ли еще что может сломаться - в ядро вшито почти неубиваемое средство сигнализировать об ошибке. Даже когда ядерная размотка стека почему-нибудь не срабатывала, по крайней мере в консоли появлялось сообщение об ошибке. А не просто молчание, как ни в чем не бывало.

Так что консольное я бы не отключал. Но окно в Вин, конечно, следует отключить, ведь это про пользователя.
Автор:  Илья Ермаков [ Вторник, 05 Январь, 2021 18:14 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
Поддерживаю Антона.
Автор:  Trurl [ Вторник, 05 Январь, 2021 18:41 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
adimetrius писал(а):
Странно, что в Вин предъявляется окно.

Это было бы странно, если бы ОС называлась Microsoft Consoles.
Автор:  Trurl [ Вторник, 05 Январь, 2021 18:43 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
Иван Денисов писал(а):
Как вы смотрите на то, чтобы SetTrapGuard полностью отключал вывод дампов?

А какая польза от этого предвидится?
Автор:  Иван Денисов [ Среда, 06 Январь, 2021 18:07 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
Trurl писал(а):
Иван Денисов писал(а):
Как вы смотрите на то, чтобы SetTrapGuard полностью отключал вывод дампов?

А какая польза от этого предвидится?

Изучаю вопрос обработки исключений при переполнении массивов, к примеру
viewtopic.php?f=134&t=6536&p=113558#p113558
Автор:  Trurl [ Среда, 06 Январь, 2021 19:32 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
А если забудете обработать?
Автор:  Иван Денисов [ Четверг, 07 Январь, 2021 08:02 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
Trurl писал(а):
А если забудете обработать?

Это какие-то исключительные случаи... даже пока не знаю какие.
После такого вызова Services.Try(s); и анализа назад незамедлительно ставится
Kernel.SetTrapGuard(FALSE);
Так что это такой явный переход в опасный режим для случаев, когда ожидается какая-то гадость от внешнего неблэкбоксовского мира. Входные данные или что-то ещё, теоретически приводящее к аварийной остановке.
Автор:  adimetrius [ Четверг, 07 Январь, 2021 14:32 ]
Заголовок сообщения:  Re: Поведение Kernel.SetTrapGuard
Польза может быть в том, чтобы не предъявлять пользователю протокол останова, изобилующий техническими (пугающими) сведениями; а вместо этого понятными пользователю словами сообщить об ошибке. Конечно, при разработке монолитных приложений (даже из компонентов от разных авторов) не должно возникать таких ситуаций - автор монолита должен предусмотреть все. Но если взаимодействуют разные приложения, то сложно все предусмотреть.

Мой прецедент: есть Гершель (заведомо нестабильное приложение в разработке) и есть тестировщик; последний должен "прогнать" Гершель по всей тестовой базе. Ессно, Гершель может "упасть". Если не пользоваться Services.SafeAction то, как понимаете, после авоста в Гершеле управление попадает в планировщик задач и будет ожидать дальнейших команд пользователя. SafeAction позволяет после авоста на некотором тесте продолжить тестирование и в конце получить агрегированный отчет: У тестов успешны, Н неудачны, О не пройдены. Поскольку авост "внутри" SafeAction возвращает управление тому, кто вызвал SafeAction, а не в планировщик.

Я не отключаю вывод протоколов авостов, покольку они мне нужны. А пользователю - может и не нужны. Например, сдают студенты работы на проверку (или конкурсанты - на конкурс). Проверить нужно все, результат нужно по каждой, а протоколы авостов - не нужны.

Есть другие способы решить те же задачи:

А) вместо SafeAction использовать Kernel.Try Напрямую; но 1) есть мнение, что не стоит импортировать ядро, и вообще его интерфейс непубличен и 2) это не типобезопасно и 3) неудобно (субъективно)

Б) Вместо временного отключения протоколов останова можно собственный написать TrapHandler; несравненно более трудоемко. Или вовсе отключать TrapHandler, но потом его трудно и не типобезопасно обратно включить

А в целом, кмк, плюс Kernel.SetTrapGuard - в том, что система более управляема.
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/