Sometimes, we may want to catch an exception, temporarily ignoring it to continue work before rethrowing it when its more appropriate to do so. I recently saw a slight variation of this whereby the developer wanted to (potentially) catch multiple exceptions, perform some processing then throw. However, it left the question that if more than one was caught, which exception should we actually rethrow. We certainly don’t want to loose any information and should really allow the client to catch the exception in a standard way.
This got me thinking about how we should deal with this kind of thing. In the end, I came up with the idea of a collection class to capture the
Exceptions and a sub-class of
Exception to represent an exception containing other, embedded exceptions. When you’re done collecting exceptions, you can just check and rethrow as a new exception type.
For example, the domain cleaning class below can throw an exception during the
deleteAll method. Rather than abandon the cleanup of subsequent objects, we can employ this tactic to continue the cleanup and throw an exception containing the underlying problems when we’re done.
We simply add to the exception collection class (
exceptions.add(e)) and then when we’re done, we can check it and throw a composite exception if needed with
So far, we’ve only been interested in the fact that multiple exception can be handled and so haven’t needed to programmatically query for specific exception types. For example, we’ve only needed this up until now.
The details of the classes are below.
toString() implementation below outputs the embedded exceptions in a way that is consistent with how you’d expect to see regular exceptions.