Pull to refresh

Мысли по поводу генерации и обработки исключений

Reading time 3 min
Views 830
На основании своего личного опыта, выработал некую концепцию работы с исключениями. Данная концепция «заточена» для приложений, основанных на бизнес-процессах. Для системных и прочих программ она может оказаться малоэффективной. Т.к. я преимущественно использую .Net, то примеры иключений приведены для .Net-платформы.

Концепция представлена в виде таблицы:
Причина генерации исключения Детали Класс исключения (.Net платформа) Как обработать исключение
1. Нарушение правил бизнес-процесса Нарушения любого внутреннего правила вашей системы.

К примеру, попытка снять средства со счета с нулевым балансом. Причем правила могут быть гибкими: для некоторых типов счетов можно разрешить уходить в минус.
Необходимо реализовать свой класс, наследник Exception (ранее рекомендовали наследоваться от ApplicationException, теперь изменили).

Обычно исключение содержит полезную для пользователя информацию.
Обработайте в соответствии с внутренними правилами вашей системы.

Чаще всего прекратить обработку текущей операции и выдать сообщение пользователю.

Записывать в лог-файл такие типы исключений не нужно.
2. Некорректные данные 2.1. Некорректные данные, вводимые пользователем. К примеру, вместо цифры введена буква. По возможности, обработать без генерации исключения (простой проверкой или использовать TryParse). Иначе, аналогично 2.2. Подсказать пользователю, какие данные являются не корректными. Предоставить возможность исправить их.

Записывать в лог-файл не нужно.
2.2. Некорректные данные от источника данных (Web-сервис, файл, реестр, база данных). К примеру, вместо XML-формата получен обычный текст. Четких правил нет.

FormatException, InvalidDataException и др.

Обычно в .Net вводят специальный класс исключения, который возникает при некорректности данных. Примеры: ConfigurationException, XmlException, SqlException, SqlTypeException, WebException. Однако возникновение этих исключений вовсе обязательно означает, что проблема именно в некорректности данных (есть другие причины).

Но вполне могут применить и ArgumentException, InvalidOperationException и пр. Это значительно усложняет обработку исключения.
Два варианта: либо поставщик данных нарушает протокол, либо подписчик не полностью реализовал обработку данных по протоколу.

Если поставщик данных не адекватен – можно подставить «костыль».

Если ваш «костыль» смог решить проблему – записывать в лог файл не нужно. Иначе записать детали в лог файл и решать проблему на одном из 2-х уровней.
3. Некорректный код 3.1. Нарушение контракта. IndexOutOfRangeException, NullReferenceException, AccessViolationException, ArgumentException, ArgumentNullException, ArgumentOutOfRangeException, InvalidCastException и др. Записать детали исключения в лог-файл, отправить лог разработчику. Такие исключения являются 100% виной разработчика.

Предупредить пользователя об ошибке. В зависимости от того где возникла ошибка, решить закрывать ли программу (если могут быть повреждены данные).

Исправить ошибку в коде на основании данных лога и обновить версию программы.
3.2. Нарушение инварианта. InvalidOperationException
4. Ошибка системы (часто связь с аппаратной проблемой).   Не устранимые:* ExecutionEngineException, StackOverflowException, OutOfMemoryException. В 99% случаев эти исключения обработать не представляется возможным. В 99% случаев – никак не обрабатывать. Можно попытаться записать данные исключения в лог.

Замечу, что данная структуризация основана на базовых понятиях:

1. Аппаратное обеспечение.
2. Программное обеспечение. В свою очередь проблемы программного обеспечения разделяются на 2 подкласса: проблема данных и проблема кода.

Так что, в принципе, ничего новго я не придумал.

Стоит заметить, что ошибки одной категории могут пораждать исключения другой категории. К примеру, некорректный код может вызвать StackOverflowException. Хотя, некорректные данные в идеале не должны вызывать ошибки некорректного кода или системные ошибки.

Хотелось бы услышать мысли по теме.
Tags:
Hubs:
+2
Comments 8
Comments Comments 8

Articles