Правильная обработка исключений?

Question

[Inyardic]

Здравствуйте. Есть класс обертка над классом. В своей обертке я предусматриваю несколько случаев, где что-то может пойти не так- переданы некорректные данные, исходный класс возвратил неправильные данные и т.п. Каждый такой случай выкидывает разные исключения.
Вопрос в том, как правильно их отлавливать при использовании класса? Перехватывать базовое исключение, или лесенкой ловить каждое конкретное?

Answer 1

[Вячеслав]

Лесенкой ловить от более частных к более общим. Последним перехватывается самое общее.

Answer 2

[Алексей Уколов]

Вопрос в том, как правильно их отлавливать при использовании класса? Перехватывать базовое исключение, или лесенкой ловить каждое конкретное?

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

Answer 3

[Дмитрий Ковальский]

Зависит от логики обработки исключений. Если вы хотите их душить просто чтобы не вылетали клиенту, а в catch их логировать, то подойдет ловля общего исключения. Если у вас напротив - самый разнообразный набор обработчиков таких ситуаций - то подход "от частного к общему сверху вниз".

Comments

[Inyardic]

Общего исключения- стоит реализовать что-то вроде MyLibBaseException или можно отлвавлить и просто стандартный общий Exception? Да, буду логгировать

[Дмитрий Ковальский]

Inyardic: Я бы начал с собственного базового. Ловить Exception конечно тоже можно, но следует понимать что туда будут падать и "чужие" исключения. Я бы в таком случае сделал сначала MyLibBaseException, а следующим "Exception". И как-то разделить логированием ошибки ваши и системные.

Answer 4

[Алексей Черемисин]

Сейчас в меня будут кидать камни... Но исключения - это зло!
Жрут кучу времени и ресурсов, часто ничего поправить уже нельзя, рвется контекст выполнения, и т.д.
Так что,
1) Делайте проверки, везде, где это возможно, используйте значения по умолчанию.
2) Если уж возникло исключение, то обрабатывать его тут же, на этом же уровне.
3) Не стоит увлекаться созданием собственных исключений! В 95% случаев ситуацию можно устранить и без них! А в остальных 5% достаточно стандартных системных.
4) Все непрерываемые исключения - обрабатывать на верхних уровнях
Вотч то я хотел сказать - java-performance.info/throwing-an-exception-in-jav...

Comments

[Андрей Данилов]

Проверки везде, где это возможно – это такое же зло, как и исключения. Если исключение даже с пустым блоком catch ещё хоть как-то можно отловить, то избегание исключений вообще может сделать баг неуловимым.

[Алексей Черемисин]

Андрей Данилов: вы меня не так поняли, избегать, не значит маскировать! Избегать, это значит проверить параметры перед их передачей, чем ловить эксепшион.

[Алексей Черемисин]

Вот что я имел сказать java-performance.info/throwing-an-exception-in-jav...

[65536]

а как стек видеть? или как без сообщения исключения понять что какой-то сто раз вызываемый метод не сработал в такой-то раз с такими-то данными/аргументами и тд. в таких случаях ручной прописи даже больше будет, тем более если ошибка фатальная, то никого кроме разработчиков это не касается, и если писать проверки для такого уровня то потом непонятно какие обычные а какие для исключений. злоупотреблять конечно не стоит

[Алексей Черемисин]

65536: А какие проблемы со стеком то будут? Там где отловите exception, там и стектрейс получите полный от места возникновения. Я я же парой комментариев выше написал, что маскировать эксепшены не нужно, просто обработайте ситуацию заранее. Например, вместо того, чтобы создавать файл по FileNotFoundException, перед открытием файла сделайте if(f.exists() && !f.isDirectory())... И если у вас работа по открытию/созданию 1000 файлов, то она заметно ускорится :-)

[Алексей Черемисин]

65536: Да и я говорил про скорость работы, а на нее как раз эксепшены очень влияют, так как тянут за собой кучу всего, в том числе и стектрейс. Ну и естественно без фанатизма. Везде должна быть мера...

Answer 5

[alexxandr]

try {
....
} catch (exception & e) {
std::cout << "Всё абсолютно ОК!" << std::endl;
}