Rethrowing the same exception - how, when and why?

Question

Hi,
I have just gone through the Exception Handling chapter and found don't understand when should I use the rethrowing of same exception?
e.g.
catch(NullPointerException e) {
e.printStackTrace();
throw e;
or
catch(NullPointerException e) {
e.printStackTrace();
Throwable changedE = e.fillInStackTrace();
throw changedE;
I am not sure how, why and when should I use this syntax?
Any advice and a given example is much appreciated.
Thanks in advance.
gogo

Answer 1

Think about the information you would want when this exception occurs; if you rethrow the exception then the entire stack trace will be available which will allow you to find the root of the problem more easily than if you have filled in the stack trace at an intermediate point in the call graph. Never throw away information in an exception.
Note also that fillInStackTrace() does not actually create a new instance of the Throwable. It just returns the same instance but with it's stack trace modified.
There are two other points to note about your example:
First, catching NullPointerExceptions or any subclass of RuntimeException (except for the curseworthy NumberFormatException) is generally a bad thing to do. RuntimeExceptions usually indicate that something is wrong with your code or with the VM and catching them is just masking the real problem. They're not like checked exceptions (subclasses of Exception that are not RuntimeExceptions) which can occur because of something 'unexpected' happening in the environment which has nothing to do with bad code and for which recovery from the problem is often possible.
Second, consider whether you really want to catch an Exception anyway. Exceptions should only be caught when:
a) you want to try to recover from the problem i.e. you can handle the exception
b) you want to transform the exception into something more meaningful to client code, i.e. if the exception comes from deep in some library code and you can't handle the exception but the actual class of exception won't be meaningful to the client code, then you might want to create your own Exception subclass and throw an instance of that in place of the original exception. If you do this, then you should chain the original exception so that you still preserve all the stack information and the original message (this is why all Throwables in JDK 1.4 have constructors that take a Throwable 'cause' parameter)
Lance