| Централизованная обработка ошибок |
Введение.
Как обработать ошибку в клиентской проге: самый простой способ засунуть все
опасные места в try except и выводить юзеру красные окошки.
Задача:
А вот если мы имеем некоторый самописный сервер (appServer, ChatServer,
почтовый), который крутится на сервере в серверной комнате, возможно как
сервис, и к нему периодически коннектится админ, чтобы посмотреть как дела.
Ошибки (и важные события, достойные попасть в лог) могут быть самые разные:
деление на ноль, файловые ошибки, нехваток памяти, попытка неавторизованного
доступа, ошибки операционной системы, SQL сервера и тд и тп.
У разных типов ошибок/сообщений может быть разный набор параметров
(например: EWin32Error имеет поле ErrorCode)
Как это красиво и централизованно оформить?
Причем интересует не только и не столько сохранение в файле, а идеи о
Variant'e для ошибок.
Andrew Rybin
Всего в теме 10 сообщений
Добавить свое сообщение
Отслеживать это обсуждение 
- Тестирование проекта. Отладка.
- Подводные камни
- Бета-тестирование
- Давайте учиться на ошибках.
- Почему программисты допускают ошибки?
- Автоматизированные тесты для GUI
- О системах контроля ошибок
- Вопросы оптимизации кода
10—1
Всего сообщений в теме: 10; страниц: 1; текущая страница: 1
| № 10 06-03-2002 17:26 |   |
| № 9 04-03-2002 23:36 | |
> Интересные у Вас наработки, честное слово. Ещё интереснее, что Вы
> напридумали ещё (не в плане обработки ошибок).
Кхммм... Серебряную пулю еще не придумал :)))
Одним из достойных своих трудов считаю библиотеку для работы с file mapping. Есть мечта сделать из нее продукт. Ну а так... по мелочам, как у всех :)
Наверно Вы все же больше напридумали :)
> Да, касательно того труда - я не совсем согласен с автором статьи
> концептуально. Номер строки есть хорошо и полезно.
> Просто надо подменить AssertErrorProc, чтобы эта працедура выводила
> ещё и билд проекта (всё через outputdebugstring и в лог).
Лично мне удобнее использовать в качестве идентификатора часть GUID. При получении ошибки достаточно сделать Find in Files, чтобы найти это место. Причем нет никакой привязки к версии исходников. После прохождения исключения по стеку (либо просто через несколько обработчиков исключений) я получаю примерно следующее:
F04AF7D4|E4BB3981|81E029DB|EE5E439C
т.е. путь исключения. Зачастую после получения от юзера такой строчки совместно с классом исключения и сообщением многое становится понятно :)
Впрочем, любая централизованная обработка ошибок требует высокой внутренней культуры написания, а исключения становятся стержнем, вокруг которого крутится работа любого продукта. Поэтому часто ловлю себя на том, что скатываюсь на обычный стиль написания (думать можно меньше). Приходится мысленно давать себе пинка :)
| № 8 04-03-2002 15:54 | |
2 Uno: Интересные у Вас наработки, честное слово. Ещё интереснее, что Вы напридумали ещё (не в плане обработки ошибок).
Да, касательно того труда - я не совсем согласен с автором статьи концептуально. Номер строки есть хорошо и полезно.
Просто надо подменить AssertErrorProc, чтобы эта працедура выводила ещё и билд проекта (всё через outputdebugstring и в лог).
| № 7 03-03-2002 00:23 | |
Ну и ещё не забываем про наличие функции OutputDebugString и утилит типа DebugView от SysInternals. Подчас самый удобный способ, и по сети мониторить можно.
| № 6 17-06-2001 02:14 | |
to Evgeny:
Спасибо за ссылку. Я тоже не просто почитал тот материал :) В моей реализации это дополнительный модуль, в котором содержатся базовая иерархия исключений (именно базовая, несколько классов всего :), функции работы с исключениями (копирование экземпляров, модификация и т.д.) и класс ExceptionList.
Наверно будет криво тут описывать все возможности этого модуля. Скажу лишь, что его применение позволяет без усилий отслеживать прохождение по стеку каждого исключения, а ExceptionList позволяет генерировать исключения не сразу, а складывать их в список. Далее список может быть сам возбужден (raised) как исключение вручную или автоматически (например, при добавлении в него фатального исключения). Его применение может быть полезно, например, при обработке множества файлов, когда ошибка одного файла не должна мешать работе с другими. А в конце можно выдать общий результат детально.
Ну все, понесло :) Одним словом, буйной фантазии есть, где развернуться. Нужно лишь помнить:
1) Исключение - это обычный объект
2) Этот объект автоматически уничтожится после обработки (on ...)
3) raise можно применить к экземпляру ЛЮБОГО класса (а не только потомка Exception)
4) Экземпляр исключения можно создать/поюзать/уничтожить вовсе не возбуждая его и не работая с ним как с исключением.
5) Класс исключения может содержать любые поля и методы (как и любой другой)
Успехов :)
| № 5 16-06-2001 16:07 | |
| № 4 17-05-2001 00:58 | |
| № 3 16-05-2001 19:40 | |
Централизованное управление давно придумано, у WinNT есть EventLog и MMC (Microsoft Management Console) - все это доступно 1) для встраивания в другие программы 2) доступно для управления/просмотра по сети. Кроме того в *nix существует SysLog сервис. Можно использовать его а можно поискать аналогичный сервис под NT (у сервиса SysLog вроде даже существует какое-то RFC). Программы, которые не поддерживают такого рода сервисы, но пишут логи, можно обмануть, написав соответствующий сервис/программу для периодического переноса их логов в стандартный (сервис сам периодически включает парсер или программа повешена на cron-е или на Scheduler service (команда AT) в NT).
| № 2 16-05-2001 17:53 | |
А те же try-catch, только в серверной программе...
Ну и использование классов исключений в соответствии с используемой средой. Это внутренние ошибки. А прикладные кроме журнала еще и клиенту передавать надо.
| № 1 16-05-2001 17:10 | |
IMHO об этом нужно думать гуру из Microsoft. Иначе все равно универсального решения не получится.
10—1
Всего сообщений в теме: 10; страниц: 1; текущая страница: 1
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
