является средством для управления исключениями с помощью блоков try, catch и finally, их своевременного выявления и соответствующего реагирования на них.
Перехватывайте выявленные исключения, только если необходимо собрать данные об исключении для протоколирования, добавить в исключение некоторые значимые данные, очистить ресурсы, используемые в блоке кода, или повторить операцию для выхода из состояния исключения. Не перехватывайте исключения с последующей их передачей вверх по стеку вызовов, если не собираетесь выполнять ни одну из вышеперечисленных задач.
Шаг 3 – Выработка стратегии распространения исключений
Рассмотрим стратегии распространения исключений. В зависимости от требований контекста приложение может (и должно) использовать сочетание любых или всех этих стратегий:
Разрешить распространение исключений. Эта стратегия хороша тем, что не требует сбора данных об исключении для протоколирования, добавления данных в исключение, очистки каких-либо ресурсов в блоке кода или повтора операции для выхода из состояния исключения. Вы просто позволяете исключению распространяться вверх по стеку кода.
Перехват и повторное формирование исключений. При такой стратегии исключение перехватывается, обрабатывается некоторым образом и повторно формируется. Обычно в этом случае данные исключения остаются нетронутыми. Применяйте эту стратегию, если требуется очищать ресурсы, протоколировать данные исключения или выполнить попытку выхода из состояния ошибки.
Перехват, обертывание и формирование исключений. Эта стратегия обеспечивает перехват универсальных исключений с последующей очисткой ресурсов или любой другой соответствующей обработкой. Если не удается обработать ошибку, исключение заключается в другое исключение, более уместное для вызывающей стороны, и после этого формируется новое исключение для обработки кодом, расположенным выше в стеке кода. Применяйте такую стратегию, если хотите сохранить уместность исключения и/или обеспечить дополнительными сведениями код, обрабатывающий исключение.
Перехват и аннулирование исключений. Эта стратегия является нерекомендуемой, но может применяться в особых случаях. Исключение перехватывается, и приложение продолжает выполняться в обычном порядке. В случае необходимости, можно зарегистрировать исключение и выполнить очистку ресурсов. Такая стратегия подходит для исключений системы, не оказывающих влияния на другие операции, такие как исключения, формируемые при заполнении журнала.
Шаг 4 – Выработка стратегии использования собственных исключений
Подумайте, существует ли необходимость в проектировании собственных исключений или достаточно будет стандартных типов исключений .NET Framework. Не используйте собственные исключения, если в иерархии исключений или в .NET Framework уже имеется подходящее исключение. Но создавайте собственные исключения, если приложение должно
выявлять и обрабатывать специальную исключительную ситуацию, чтобы избежать применения условной логики, или если необходимо включить дополнительные данные для выполнения определенного требования.
Если все-таки приходится создавать собственные классы исключений, применяйте в них стандартные конструкторы, включая конструктор сериализации, и обязательно заканчивайте имя класса словом «Exception» (Исключение). Это важно для обеспечения интеграции со стандартным механизмом исключений. Реализуйте собственное исключения путем наследования от подходящего более общего исключения и его специализации соответственно конкретным требованиям.
В общем, при проектировании стратегии управления исключениями вы должны создавать иерархию исключений и организовывать собственные исключения в ее рамках. Это поможет пользователям быстро анализировать и прослеживать возникающие проблемы. В собственных исключениях должен быть указан слой, в котором было сформировано исключение, компонент, в котором, возможно, возникло исключение, и тип сформированного исключения (такой как исключение безопасности, бизнес-логики или системное исключение).
Храните иерархию исключений приложения в отдельной сборке, на которую может ссылаться код приложения. Это поможет централизовать управление и развертывание классов исключений. Также продумайте, как будет выполняться передача исключений через физические границы, границы процессов или AppDomain. Классы .NET Framework Exception поддерживают сериализацию. При проектировании собственных классов исключений обеспечьте, чтобы они также поддерживали сериализацию.
Шаг 5 – Выбор соответствующих данных для сбора
Один из наиболее важных аспектов при обработке исключений – правильный выбор стратегии сбора данных исключения. Перехватываемые сведения должны точно представлять условие возникновения исключения. Также они должны быть значимыми и информативными для аудитории. Можно выделить три категории аудитории: конечные пользователи, разработчики приложения и операторы. На основании сценария и индивидуального контекста установите, кому адресовано исключение.
Для конечных пользователей требуется осмысленное и хорошо представленное описание. При сборе данных исключения для конечных пользователей позаботьтесь, чтобы они были поданы в виде понятного пользователям сообщения, описывающего природу ошибки и предлагающего пути восстановления после такой ошибки, если это возможно. Разработчикам приложения необходимы более подробные сведения, которые помогут в диагностике проблемы.
Разработчикам приложения необходимы данные о точном месте возникновения исключения в коде, а также такие сведения, как тип исключения и состояние системы в момент возникновения исключения. Операторам службы поддержки должна предоставляться соответствующая информация, которая позволит им реагировать соответствующим образом и предпринять необходимые шаги по восстановлению системы после ошибки. При сборе данных исключения для операторов службы поддержки обеспечьте сведения, которые помогут им найти людей, которых они должны уведомить об исключении, и информацию, которую они должны будут передать для решения проблемы.
Независимо от целевой аудитории всегда полезно обеспечивать исчерпывающую информацию об исключении. Сохраняйте эти сведения в файле журнала для последующей проверки и анализа частоты возникновения исключений и их данных. По умолчанию должны фиксироваться, как минимум, дата и время, имя компьютера, источник исключения и тип, сообщение об исключении, данные о стеке и вызовах, доменное имя приложения, имя и версия сборки, ID потока и сведения о пользователе.
Шаг 6 – Выработка стратегии протоколирования исключений
Существует ряд возможных вариантов протоколирования данных исключения. Следующие основные соображения помогут сделать правильный выбор:
Используйте Windows Event Log (Журнал регистрации событий Windows) или Windows Eventing 6.0, если приложение развернуто на одном компьютере, если необходимо использовать существующие инструменты для просмотра журнала, или если надежность является основным требованием.
Используйте SQL Database, если приложение развернуто на ферме или в кластере, если необходимо обеспечить централизованное протоколирование, или если требуется гибкость в структурировании и протоколировании данных исключения.
Используйте собственный файл журнала, если приложение развернуто на одном компьютере, если необходима абсолютная гибкость выбора формата протоколирования, или если хотите просто и легко реализовать хранилище журнала регистрации. Контролируйте размер файла журнала, периодически очищая или архивируя журнал, чтобы он не разрастался в размерах.
Выбирайте Message Queuing в качестве механизма доставки для передачи сообщений об исключениях в точку их окончательного назначения, если надежность является главным требованием, если приложения развернуты на ферме или в кластере, или если требуется централизовать протоколирование.
Влюбом приложении может использоваться несколько из представленных вариантов в зависимости от сценария и политики обработки исключений. Например, исключения безопасности могут протоколироваться в Security Event Log, а исключения бизнес-логики – в базу данных.
Шаг 7 – Выбор стратегии уведомления об исключениях
При выработке стратегии управления исключениями необходимо также принять решение о стратегии уведомления. Часто в корпоративных приложениях только управления исключениями и протоколирования не достаточно. Необходимо предусмотреть также уведомления, чтобы обеспечить информирование о возникающих исключениях администраторов и операторов. Для этого могут использоваться такие технологии, как события WMI, электронные письма SMTP, текстовые сообщения SMS или другие системы уведомления.
Рассмотрите возможность использования внешних механизмов уведомления, таких как системы мониторинга журналов или среды сторонних производителей, которые выявляют в данных журнала условия возникновения ошибки и формируют соответствующие уведомления.