Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
В статье прочитал набор несколько частных случаев исключений и общие мысли по их обработке.
Где концепция?
Где концепция?
В вашем случае используется большое количество эксепшенов, и как следствие для обработки одного try, может быть несколько catch. Мне такой вариант никогда не нравился, идеальным вариантом для меня было максимум 2 catch'a.
Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение), и в зависимости от типа исключения принимаю решение о логировании.
Второй эксепшен — это базовый для всех класс Exception, которым ловлю все не мои исключения.
Таким образом, в одном catch'e я могу обработать большинство исключений и выдать сообщенеи пользователю.
Такая модель для меня стала удобной. Быть может в ней есть и минусы, которые я не замечаю — буду рад, если об этом сообщат=)
Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение), и в зависимости от типа исключения принимаю решение о логировании.
Второй эксепшен — это базовый для всех класс Exception, которым ловлю все не мои исключения.
Таким образом, в одном catch'e я могу обработать большинство исключений и выдать сообщенеи пользователю.
Такая модель для меня стала удобной. Быть может в ней есть и минусы, которые я не замечаю — буду рад, если об этом сообщат=)
>>Второй эксепшен — это базовый для всех класс Exception, которым ловлю все не мои исключения.
Давайте попробую ответить в ракурсе концепции.
Наверняка вы читали в MSDN, что не рекомендуется перехватывать базовый класс Exception. И как и 90% разработчиков, не найдя в этом большого смысла, проигнорировали эту рекомендацию. На самом деле смысл есть. В первую очередь вы «нейтрализуете» (пытаетесь нейтрализовать) исключения нижнего уровня, к примеру такие как ExecutionEngineException, OutOfMemoryException. В некоторых случаях это может повлечь повреждение данных (программа некоторое время продолжит работу, затем упадет). Как минимум после перехвата вам нужно проверить было ли исключение низкоуровневым и если было — закрыть программу.
Большинство об этом не задумываются. И поскольку низкоуровневые проблемы возникают редко — программа вроде как нормально работает.
>>Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение)
Если я правильно понял, то это первый тип исключений из таблицы? Исключения «нарушения правил бизенс-логики» вы выделяете — это правильно.
Но все-же и исключения «некорректности данных» и «некорректности кода» нужно отличать от «системных» (системные — это низкоуровневые, а не наследники SystemException!).
Некорректные данные выгодно отличать уже потому, что это не ваша вина. Вы всегда можете выдать сообщение пользователю: от сервиса банка «Пупсобанк» получен некорректный ответ. И польователь будет негодовать на их сервис, а не на вашу программу. Именно для этого я и различаю проблемы кода и проблемы данных.
Давайте попробую ответить в ракурсе концепции.
Наверняка вы читали в MSDN, что не рекомендуется перехватывать базовый класс Exception. И как и 90% разработчиков, не найдя в этом большого смысла, проигнорировали эту рекомендацию. На самом деле смысл есть. В первую очередь вы «нейтрализуете» (пытаетесь нейтрализовать) исключения нижнего уровня, к примеру такие как ExecutionEngineException, OutOfMemoryException. В некоторых случаях это может повлечь повреждение данных (программа некоторое время продолжит работу, затем упадет). Как минимум после перехвата вам нужно проверить было ли исключение низкоуровневым и если было — закрыть программу.
Большинство об этом не задумываются. И поскольку низкоуровневые проблемы возникают редко — программа вроде как нормально работает.
>>Для этих целей я использую один свой эксепшен, при генерации которого указываю его тип (проверка данных, критическая ошибка, предупреждение, инфомрационное сообщение)
Если я правильно понял, то это первый тип исключений из таблицы? Исключения «нарушения правил бизенс-логики» вы выделяете — это правильно.
Но все-же и исключения «некорректности данных» и «некорректности кода» нужно отличать от «системных» (системные — это низкоуровневые, а не наследники SystemException!).
Некорректные данные выгодно отличать уже потому, что это не ваша вина. Вы всегда можете выдать сообщение пользователю: от сервиса банка «Пупсобанк» получен некорректный ответ. И польователь будет негодовать на их сервис, а не на вашу программу. Именно для этого я и различаю проблемы кода и проблемы данных.
Необходимо реализовать свой класс, наследник Exception (ранее рекомендовали наследоваться от ApplicationException, теперь изменили)
А чем ApplicationException для этих целей плох? Ну или наследник ApplicationException.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мысли по поводу генерации и обработки исключений