Catching an exception that is nested into another exception

Question

Hi,

I want to catch an exception, that is nested into another exception. I'm doing it currently this way:

} catch (RemoteAccessException e) {
            if (e != null && e.getCause() != null && e.getCause().getCause() != null) {
            MyException etrp = (MyException) e.getCause().getCause();
            ...
            } else {
            throw new IllegalStateException("Error at calling service 'beitragskontonrVerwalten'");
            }
        }

Is there a way to do this more efficient and elegant?

Answer 1

I doubt, but you can check with instanceof if the exception is of the correct type.

Edit: There should be a reason that the nested exception is wrapped, so you have to ask yourself what is the purpose of catching the nested one.

Answer 2

You should add some checks to see if e.getCause().getCause() is really a MyException. Otherwise this code will throw a ClassCastException. I would probably write this like:

} 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("...");
    }
}

Answer 3

I see no reason why you want exception handling to be efficient and elegant, I settle for effective. They're called Exceptions for a reason.

This code will be a maintenance nightmare. Can't you redesign the call stack to throw the Exception you are interested in? If it is important the method signatures should show it and not hide it wrapped in 2 other exceptions.

The first (e != null) is unnecessary.

And you can change the 3rd better to e.getCause().getCause() instanceof MyException)

Answer 4

There is no more elegant way of selectively "catching" nested exceptions. I suppose if you did this kind of nested exception catching a lot, you could possibly refactor the code into a common utility method. But it still won't be either elegant or efficient.

The elegant solution is to do away with the exception nesting. Either don't chain the exceptions in the first place, or (selectively) unwrap and rethrow the nested exceptions further up the stack.

Exceptions tend to be nested for 3 reasons:

• You have decided that the details of the original exception are unlikely to be useful for the application's error recovery ... but you want to preserve them for diagnostic purposes.

• You are implementing API methods that doesn't allow checked exceptions but your code (unavoidably) throws such exceptions. (A common workaround is to "smuggle" the exception inside an unchecked exception.)

• You are being lazy and turning a diverse set of exceptions into a single exception to avoid having lots of checked exceptions in your method signature.

In the first case, if you need to discriminate on the wrapped exceptions your initial assumptions / design is incorrect, and the ideal solution is change method signatures so that you can get rid of the nesting.

In the second case, you probably should unwrap the exceptions as soon as control has passed the problematic API method.

In the third case, you should rethink your exception handling strategy; i.e. do it properly.