OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:17

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 9 ] 
Автор Сообщение
 Заголовок сообщения: #044 Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Понедельник, 04 Январь, 2021 17:50 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Есть в ядре процедура, которая позволяет отключить вывод дампов во время аварийных остановок.
С наличием Services.SafeAction это позволяет делать интересные варианты для обработки исключений.
Однако полного отключения не происходит, срабатывает диалог для обработки по-умолчанию.
В Linux — это вывод сообщений в консоль, а вот в Windows версии ошибки всплывают в виде диалоговых окон.

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


Как вы смотрите на то, чтобы SetTrapGuard полностью отключал вывод дампов? В целом примерно так и ожидается согласно имеющейся благодаря усилиям Ильи Ермакова и Александра Ильина документации.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Вторник, 05 Январь, 2021 13:46 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Странно, что в Вин предъявляется окно.

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

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

Так что консольное я бы не отключал. Но окно в Вин, конечно, следует отключить, ведь это про пользователя.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Вторник, 05 Январь, 2021 18:14 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Поддерживаю Антона.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Вторник, 05 Январь, 2021 18:41 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
adimetrius писал(а):
Странно, что в Вин предъявляется окно.

Это было бы странно, если бы ОС называлась Microsoft Consoles.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Вторник, 05 Январь, 2021 18:43 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Иван Денисов писал(а):
Как вы смотрите на то, чтобы SetTrapGuard полностью отключал вывод дампов?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Среда, 06 Январь, 2021 18:07 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Trurl писал(а):
Иван Денисов писал(а):
Как вы смотрите на то, чтобы SetTrapGuard полностью отключал вывод дампов?

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

Изучаю вопрос обработки исключений при переполнении массивов, к примеру
viewtopic.php?f=134&t=6536&p=113558#p113558


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Среда, 06 Январь, 2021 19:32 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
А если забудете обработать?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Четверг, 07 Январь, 2021 08:02 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Trurl писал(а):
А если забудете обработать?

Это какие-то исключительные случаи... даже пока не знаю какие.
После такого вызова Services.Try(s); и анализа назад незамедлительно ставится
Kernel.SetTrapGuard(FALSE);
Так что это такой явный переход в опасный режим для случаев, когда ожидается какая-то гадость от внешнего неблэкбоксовского мира. Входные данные или что-то ещё, теоретически приводящее к аварийной остановке.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Поведение Kernel.SetTrapGuard
СообщениеДобавлено: Четверг, 07 Январь, 2021 14:32 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Польза может быть в том, чтобы не предъявлять пользователю протокол останова, изобилующий техническими (пугающими) сведениями; а вместо этого понятными пользователю словами сообщить об ошибке. Конечно, при разработке монолитных приложений (даже из компонентов от разных авторов) не должно возникать таких ситуаций - автор монолита должен предусмотреть все. Но если взаимодействуют разные приложения, то сложно все предусмотреть.

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

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

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

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

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

А в целом, кмк, плюс Kernel.SetTrapGuard - в том, что система более управляема.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 9 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB