объект цепочки исключений в JAVA

Question

объект цепочки исключений в JAVA

1

Я могу установить привязанный объект Exception в java как

Дело 1:

public static void main(String[] args) {

    try {
        method1();
    } catch (Exception e) {
        System.out.println("Exception in the main method :: "+e);
    }

}

private static void method1() throws Exception {
    try{
        System.out.println("Inside Try Block"+10/0);
    } catch(ArithmeticException e){
        System.out.println("Exception in method1 :: "+e);
        throw e;
    } finally{
        System.out.println("In FinallY Block");
    }

}

случай 2:

public static void main(String[] args) {

    try {
        method1();
    } catch (Exception e) {
        System.out.println("Exception in the main method :: "+e);
    }

}

private static void method1() throws Exception {
    try{
        System.out.println("Inside Try Block"+10/0);
    } catch(ArithmeticException e){
        System.out.println("Exception in method1 :: "+e);
        throw (ArithmeticException)new ArithmeticException().initCause(e);
    } finally{
        System.out.println("In FinallY Block");
    }
}

И я получил результат как

Exception in method1 :: java.lang.ArithmeticException: / by zero
In FinallY Block
Exception in the main method :: java.lang.ArithmeticException: / by zero

И мой вопрос:

Есть ли разница между этими двумя случаями?
Какой метод лучше?
И почему 2 случая с той же целью?

Rakesh KR 19 март 2014, в 17:06

Источник

Теги:

java

exception

2 ответа

1

Вы должны передать причину в качестве аргумента конструктора вместо вызова initCause.

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

Таким образом, вы бы сделали что-то вроде:

private static void method1() throws HigherLevelException {
    try{
        System.out.println("Inside Try Block"+10/0);
    } catch(ArithmeticException e){
        throw new HigherLevelException(e);
    }
}

Поскольку многие считают, что проверенные исключения являются неудачным экспериментом (даже точка-сеть не выбрала их для копирования), во многих случаях исключение более высокого уровня имеет тенденцию быть неконтролируемым исключением. Вы увидите этот шаблон с Spring и Hibernate.

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

Nathan Hughes 19 март 2014, в 13:40

Ещё вопросы

Joffrey · Accepted Answer · 2014-03-19T14-23-00.000Z

Разница заключается в том, что вы завершаете исходное исключение ArithmeticException в другом исключении того же типа во втором случае (см. Ниже, почему это бессмысленно).
Случай 1, вероятно, вы хотите использовать здесь, потому что вы не расширяете значение своего исключения (на более высокий уровень).
У них нет той же цели, позвольте мне объяснить...

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

Случай, когда вам может понадобиться причина, например, когда вы пытаетесь получить некоторые данные из веб-службы: низкоуровневые методы, отправляющие HTTP-запросы, SocketException некоторое SocketException или HttpException и обертывают их некоторыми исключениями более высокого уровня, описывая, какой ресурс не может быть загружена (например).