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/ |