Jak uzyskać poprawnie powiązany ślad stosu dla wyjątków zgłaszanych podczas obsługi innych wyjątków?

Question

Załóżmy, że obsługuję FooException i BarException. Załóżmy, że oba są niezaznaczonymi wyjątkami.

Co chcę zobaczyć w stacktrace jest:

com.bar.BarException: Bar Message 
    at com.baz.BazCode(BazCode.java:123) 
    ... 
Caused by: com.foo.FooException: Foo Message 
    at com.baz.BazCode(BazCode.java:321) 
    .... 
Caused by: ... 

Jednak domyślnie cały zapis FooException zostaną usunięte z stacktrace. Na przykład:

// In a class written by me 
/** 
    * ... 
    * @throws FooException if foo happens 
    * @throws BarException if bar happens 
    */ 
public void upperFrame() { 
    try { 
     foo.doSomething(); 
    } catch (FooException foo) { 
     bar.doSomethingElse(); 
    } 
} 

// In class Bar (not written by me) 
public void doSomethingElse() { 
    if (someConditionWhichHappensToBeTrueInThisScenario()) { 
     throw new BarException("Hello Bar World"); // At this point, FooException gets erased from the stack trace 
    } 
} 

Jeśli BarException ma (message, cause) konstruktora wtedy mogę śledzić raczej surowy rodzaj procesu „instrukcja klonowania”, aby osiągnąć mój cel:

try { 
    foo.doSomething(); 
} catch (FooException foo) { 
    try { 
     bar.doSomethingElse(); 
    } catch (BarException bar) { 
     BarException bar2 = new BarException(bar.getMessage(), foo); 
     bar2.setStackTrace(bar.getStackTrace()); 
     throw bar2; 
    } 
} 

Jednak jeśli BarException nie ma takich konstruktor (np ClassCastException) to jestem zredukowana do robienia rzeczy tak:

try { 
    foo.doSomething(); 
} catch (FooException foo) { 
    try { 
     bar.doSomethingElse(); 
    } catch (BarException bar) { 
     RuntimeException e = new RuntimeException("com.bar.BarException: " + bar.getMessage(), foo); 
     e.setStackTrace(bar.getStackTrace()); 
     throw e; 
    } 
} 

jest to niebezpieczne be powoduje, że e ma niewłaściwy typ i dlatego może nie być poprawnie obsługiwany przez wyższe ramki.

Czy istnieje sposób "najlepszej praktyki" radzenia sobie z tą sytuacją?

Answer 1

Jednym z rozwiązań jest użycie metody Throwable#initCause(Throwable):

bar.initCause(foo); 

Answer 2

Dopóki przekazać oryginalny wyjątek nowym jako argument, że tworzy „spowodowane przez” łańcucha i ślad stosu jest zachowana . Twoje przypadki użycia wydają się nieco dziwne. Dla mnie wyjątek podczas odzyskiwania lub obsługi błędu z więcej niż niektórych rejestrowania jest kolejnym błędem, a nie "spowodowany" przez inny błąd. Chciałbym po prostu zalogować "foo" i rzucić "pasek".

W niektórych przypadkach wydaje mi się, że Twój sposób może mieć sens. Aby to zrobić, możesz przekazać "foo" jako doSomethingElse (foo) i rzucić nowy wyjątek BarException (foo), gdy coś pójdzie nie tak. Prawie wszystkie standardowe wyjątki obsługują ten konstruktor, a jeśli potrzebujesz stworzyć własne, po prostu utwórz konstruktora, który je deleguje.

Ja osobiście nie użyłbym ich tak, jak wydaje się. Używam ich do rzucania innego rodzaju wyjątku niż ten, który złapałem, jeśli z jakiegoś powodu chcę innego typu. Na przykład, aby tłumaczyć na wyjątki określonego typu do mojej aplikacji lub tłumaczyć zaznaczone na niezaznaczone w przypadkach, w których ma to sens. W takich przypadkach nadal dobrze jest zachować oryginalny wyjątek i pełne "spowodowane przez .." śledzenie ..