Ловля исключения, которое вкладывается в другое исключение

Question

Ловля исключения, которое вкладывается в другое исключение

Потоки не выполняются параллельно в cpython. Попробуйте вместо этого использовать ProcessPoolExecutor.

26

nested-exceptions try-catch exception java

задан Clint 22 October 2018 в 00:51

4 ответа

Я сомневаюсь, но вы можете проверить с instanceof, если исключение имеет правильный тип.

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

0

ответ дан Petar Minchev 28 November 2019 в 06:26

Я не вижу причин, по которым вы хотите, чтобы обработка исключений была эффективной и элегантной, я согласен на эффективность. Они называются исключениями по причине.

Этот код будет кошмаром обслуживания. Разве вы не можете перепроектировать стек вызовов, чтобы создать интересующее вас исключение? Если это важно, сигнатуры методов должны показывать это, а не скрывать, заключенные в 2 других исключения.

Первый (e! = Null) не нужен.

И вы можете изменить третий лучше на e.getCause (). GetCause () instanceof MyException)

2

ответ дан Peter Tillemans 28 November 2019 в 06:26

Вам следует добавить несколько проверок, чтобы увидеть, действительно ли e.getCause (). GetCause () является MyException . В противном случае этот код вызовет исключение ClassCastException . Я бы, вероятно, написал это так:

} catch(RemoteAccessException e) {
    if(e.getCause() != null && e.getCause().getCause() instanceof MyException) {
        MyException ex = (MyException)e.getCause().getCause();
        // Do further useful stuff
    } else {
        throw new IllegalStateException("...");
    }
}

18

ответ дан 28 November 2019 в 06:26

Другие вопросы по тегам:

nested-exceptions try-catch exception java

Похожие вопросы:

score 26 · Accepted Answer

Нет более элегантного способа выборочного «перехвата» вложенных исключений. Я полагаю, если бы вы сделали такое вложенное исключение, улавливающее много, вы могли бы реорганизовать код в общий служебный метод. Но все равно не будет ни элегантным, ни эффективным.

Элегантное решение - отказаться от вложенности исключений. Либо не связывайте исключения в первую очередь, либо (выборочно) разворачивайте и повторно генерируйте вложенные исключения дальше по стеку.

Исключения имеют тенденцию быть вложенными по трем причинам:

Вы решили, что подробности исходного исключения вряд ли будут полезны для исправления ошибок приложения ... но вы хотите сохранить их для диагностических целей.
Вы реализуете методы API, которые не разрешают конкретное проверенное исключение, но ваш код неизбежно генерирует это исключение. Обычный обходной путь - «переместить» проверенное исключение внутрь непроверенного исключения.
Вы ленитесь и превращаете разнообразный набор несвязанных исключений в одно исключение, чтобы избежать наличия большого количества проверенных исключений в сигнатуре вашего метода ¹.

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

Во втором случае вам, вероятно, следует развернуть исключения, как только управление будет передано проблемному методу API.

В третьем случае вам следует переосмыслить свою стратегию обработки исключений; т.е. делать это правильно ².

^{1 - Действительно, одна из полузаконных причин для этого исчезла из-за введения синтаксиса перехвата с несколькими исключениями в Java 7.}

^{2 - Не меняйте методы API на выбрасывает исключение . Это только усугубляет ситуацию. Теперь вы должны либо «обрабатывать», либо распространять Exception каждый раз, когда вы вызываете методы. Это рак ...}