Как стать автором
Обновить

Комментарии 8

В статье прочитал набор несколько частных случаев исключений и общие мысли по их обработке.
Где концепция?
Давайте практический вопрос, попробую ответить на основании информации из таблицы.

P.S.
Ну вы сами понимаете: для подробного рассмотрения всех случаев — нужна целая книга. Здесь больше похоже на шпаргалку.
В вашем случае используется большое количество эксепшенов, и как следствие для обработки одного try, может быть несколько catch. Мне такой вариант никогда не нравился, идеальным вариантом для меня было максимум 2 catch'a.
Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение), и в зависимости от типа исключения принимаю решение о логировании.
Второй эксепшен — это базовый для всех класс Exception, которым ловлю все не мои исключения.

Таким образом, в одном catch'e я могу обработать большинство исключений и выдать сообщенеи пользователю.

Такая модель для меня стала удобной. Быть может в ней есть и минусы, которые я не замечаю — буду рад, если об этом сообщат=)
Ответил вам ниже.
>>Второй эксепшен — это базовый для всех класс Exception, которым ловлю все не мои исключения.

Давайте попробую ответить в ракурсе концепции.

Наверняка вы читали в MSDN, что не рекомендуется перехватывать базовый класс Exception. И как и 90% разработчиков, не найдя в этом большого смысла, проигнорировали эту рекомендацию. На самом деле смысл есть. В первую очередь вы «нейтрализуете» (пытаетесь нейтрализовать) исключения нижнего уровня, к примеру такие как ExecutionEngineException, OutOfMemoryException. В некоторых случаях это может повлечь повреждение данных (программа некоторое время продолжит работу, затем упадет). Как минимум после перехвата вам нужно проверить было ли исключение низкоуровневым и если было — закрыть программу.

Большинство об этом не задумываются. И поскольку низкоуровневые проблемы возникают редко — программа вроде как нормально работает.

>>Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение)

Если я правильно понял, то это первый тип исключений из таблицы? Исключения «нарушения правил бизенс-логики» вы выделяете — это правильно.

Но все-же и исключения «некорректности данных» и «некорректности кода» нужно отличать от «системных» (системные — это низкоуровневые, а не наследники SystemException!).

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

А чем ApplicationException для этих целей плох? Ну или наследник ApplicationException.
Ранее так и рекомендовали делать. Потом рекомендации изменили (см. MSDN). Причину указали: «это не имеет смысла».
Весьма туманный аргумент.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории