Обработка и логирование исключений под Windows и в веб сервисах (часть 10)
2013-08-08 22:04:00 (читать в оригинале)
Продолжаю цикл переводов понравившейся мне статьи автора James Dingle про исключения.
Первый пост посвященный этой статье находится здесь.
8. Обрушивайтесь правильно
В соответствии с правилом " 5 - Не проглатывать исключений ",
некоторые разработчики предполагают, что их приложение должно быть всегда работающим.
Таким образом они думают, что лучше пусть приложение поймает все исключения и останется на плаву.
Они оценивают такое поведение как образец надежности приложения.
И действительно, это звучит противоречащим интуиции, что обрушивание приложения может повысить его надежность.
Такой образ мысли зависит от ситуации, но самое главное он не полный (то есть он не учитывает всего).
Что в данном случае действительно важно, так это как просто и безболезненно расследовать падение приложения.
Выбор продолжать ли выполнение или остановить приложение является менее приоритетной задачей.
Возможны ситуации, когда лучше не продолжать выполнение приложения и обрушиться. На это есть следующие причины:
-
Приложение находится в состоянии, когда дальнейшее выполнение может повредить данные или внутреннюю логику.
В данном случае лучше выполнить "очищающий крах", чем продолжить "грязное выполнение".
Крах позволит рестартовать приложению с хорошо известной точки (из правильного состояния).
-
Времена, когда крах обозначался невразумительным message box ("Access memory violation at 0x00054357") с бесполезным дампом стека, уже прошли.
Это тот случай когда вы не можете подключить отладчик к приложению.
Потому что вы поставили ваше приложение пользователю (клиенту), или потому что вы не имеете доступа к продакшн окружению.
Надежда на лишь то, что дампы стека просты в использовании и высоко ценны в наше время.
-
Если ваше приложение это служба Windows под Windows 2008, то не пойманное исключение будет логировано как Windows Event вместе с дампом стека.
И мини дампы будут созданы автоматически вместе с Windows Error Reporting.
Вы можете сконфигурировать вашу службу Windows рестартовать автоматически.
-
.Net предлагает API Environment.FailFastwhich, который также генерирует дамп стека и лог исключений.
-
Получение большего числа ошибок во время фаз разработки и тестирования увеличивает основное качество приложения.
Если ошибки всегда ловятся, или что еще хуже тихо игнорируются.
То они могут остаться неизвестными или попасть вниз списка "известных предупреждений", которые никому не хватит времени расследовать.
Если проблемы сохранены в отчет и их просто чинить, то в конце вы получите приложение более высокого качества, без изменений навыков команды разработчиков.
Если ошибки игнорируются или требуют мучительных расследований.
То только высокоприоритетные проблемы будут решены и продукт будет поставлен с большим количеством ошибок.
-
В больших и/или распределенных продакшн окружениях проблемное звено будет обнаружено быстрее, если приложение обрушится.
Все за и против, а также возможные преимущества и недостатки зависят от процессов и команды в вашей компании.
Однако:
-
Подумайте об деградации (усечении функционала) перед падением.
Падение должно быть последним решением, реакцией на событие, которое ваше приложение несомненно не сможет обработать.
Если некоторая возможность не жизненно необходима для вашего приложения, то это не хорошо, если она приведет к падению всего приложения.
Однако, это должно быть проконтролированно в логике кода.
"Продолжение при любых ошибках" не приемлимый путь для реализации режима усеченного функионала.
Потому что поведение приложения не предсказуемо.
-
"Конфигурационный файл нечитаем", "база данных не существует", "диск переполнен"
могут быть валидными сценариями для того, чтобы опрокинуть ваше приложение с копыт.
Но ваше приложение может также продолжить работу с настройками производителя по умолчанию, создав недостающую БД, или продолжая работать в режиме read-only.
Все на самом деле зависит от требований и функциональности вашего приложения.
-
Крах может быть концом экземпляра вашего приложения.
Но он же может не быть концом жизненного цикла.
Бизнес должен понимать ущерб от проблемы.
Команда поддержки должна понимать как она может обойти проблему.
А команда разработки должна иметь возможность пофиксить ее.
Это должно быть частью архитектуры обработки ошибок приложением.
Windows Error Reporting это прекрасная возможность (функционал) предоставленный нам в Windows 2008.
По умолчанию, Windows Error Reporting пытается загрузить информацию о крахе в Microsoft и удалить ее когдв все будет кончено.
Вы можете настроить ключами реестра эту подсистему так, чтобы она сохраняла дамп краха на диск во всех случаях вашего собственного исследования.
Подробнее прочитать как это сделать можно здесь.
Продолжение следует ...
