Question

Suppose i have a method that may fail with a checked exception (checked because it is recoverable, according to Sun’s recommendations).
This method fails and it triggers a recovery strategy.
But both the initial method and the recovery strategy failed.

In some cases i may want to have both stacktraces so that i know why both the initial and recovery strategies failed, and not only the last one.

What can i do?
Should i create a CompositeException type or something like that? Is it a good practice?

Answer 1

Java 7 has introduced the concept of a suppressed exception. For instance, the try-with-resources statement is specified by:

Resources are closed in the reverse order from that in which they were initialized. A resource is closed only if it initialized to a non-null value. An exception from the closing of one resource does not prevent the closing of other resources. Such an exception is suppressed if an exception was thrown previously by an initializer, the try block, or the closing of a resource.

and

• If the initialization of the resource completes normally, and the try block completes abruptly because of a throw of a value V, then:

  • If the automatic closing of the resource completes abruptly because of a throw of a value V2, then the try-with-resources statement completes abruptly because of a throw of value V with V2 added to the suppressed exception list of V.

This uses java.lang.Throwable.addSuppressedException, whose javadoc reads:

Appends the specified exception to the exceptions that were suppressed in order to deliver this exception. This method is thread-safe and typically called (automatically and implicitly) by the try-with-resources statement.

The suppression behavior is enabled unless disabled via a constructor. When suppression is disabled, this method does nothing other than to validate its argument.

Note that when one exception causes another exception, the first exception is usually caught and then the second exception is thrown in response. In other words, there is a causal connection between the two exceptions. In contrast, there are situations where two independent exceptions can be thrown in sibling code blocks, in particular in the try block of a try-with-resources statement and the compiler-generated finally block which closes the resource. In these situations, only one of the thrown exceptions can be propagated. In the try-with-resources statement, when there are two such exceptions, the exception originating from the try block is propagated and the exception from the finally block is added to the list of exceptions suppressed by the exception from the try block. As an exception unwinds the stack, it can accumulate multiple suppressed exceptions.

An exception may have suppressed exceptions while also being caused by another exception. Whether or not an exception has a cause is semantically known at the time of its creation, unlike whether or not an exception will suppress other exceptions which is typically only determined after an exception is thrown.

Note that programmer written code is also able to take advantage of calling this method in situations where there are multiple sibling exceptions and only one can be propagated.

That last paragraph seems to apply to your situation. So you could do:

public static void main(String[] args) throws Exception {
    try {
        throw new RuntimeException("Not now!");
    } catch (Exception e) {
        try {
            tryAgain();
        } catch (Exception e2) {
            e.addSuppressed(e2);
            throw e;
        }
    }
}

Then, the stack trace will contain both exceptions:

Exception in thread "main" java.lang.RuntimeException: Not now!
    at tools.Test.main(Test.java:12)
    Suppressed: java.lang.RuntimeException: I'm on holiday.
        at tools.Test.tryAgain(Test.java:7)
        at tools.Test.main(Test.java:15)

but only the primary exception can be caught by the caller.