Java - Difference between throwing an Exception and catching and rethrowing Exception

Question

I'm confused as to what the beneift would be in catching and rethrowing an exception versus just throwing it in the first place.

For example

private void testMethod() throws Exception
{
    //some bad code here
} 

versus:

private void testMethod() throws Exception
{
    try
    {
        //some bad code here
    }
    catch (Exception e)
    {
        throw e;
    }
} //end testMethod()

Is this to preserve the stack trace of the error message? I tried setting up an example, but didn't see any different output between the two.

Thanks for the help.

Answer 1

There is no difference in behaviour between your two code samples. (In particular, stacktraces are recorded when an exception is created, not when it is thrown, so a rethrown exception will still have the original stack trace). Usually, people therefore use the simpler idiom.

That is not to say rethrowing doesn't have its uses. For instance, if you wanted to handle all exceptions except FooBarExceptions, you could write:

try {
    // bad code 
} catch (FooBarException e) {
    throw e;
} catch (Exception e) {
    e.printStackTrace();
}

Or if the decision to handle an exception is more involved than simply checking its type, you can simply catch it, and rethrow if it turns out you can't handle it:

for (int attempts = 0; attemps < 6; attempts++) {
    try {
        return crankyMethod();
    } catch (Exception e) {
        if (fatal(e)) {
            throw e;
        } else {
            // try again
            continue;
        }
    }
}

It is worth noting that when people say rethrow, some mean to throw a different exception, as in the following example:

for (int i = 0; i < array.length; i++) {
    try {
        process(array[i]);
    } catch (Exception e) {
        throw new RuntimeException("Could not process element at index " + i, e);
    }
}

The advantage of this pattern is to decorate the original exception with additional information that might be relevant (in the above example: what data could not be processed). Note that the original exception is passed to the constructor of the new one, so its stack trace is not lost.

Answer 2

As others have said, in your example there is no difference, and the 2nd form should be avoided.

The only place where it sometimes makes sense is where you need to catch some exceptions, and let others get thrown upwards. Because Java's exception handling syntax is limited, sometime you might do this:

try {
   somePieceOfCode();
} catch( RuntimeException e ) {
   throw e;
} catch( Exception e ) {
   handleException(e);
}

This is sometimes done if somePieceOfCode throws a number of different checked exceptions that don't have a common base class (other than Exception) but need to be handled in the same way. You might not want to just catch Exception because that would also catch things like NullPointerException, and you might prefer for those exceptions to bubble up as-is.

This code will let all RuntimeExceptions bubble upwards, but handle all other exceptions.

This idiom is little unusual, and not everyone likes it, but you might see it in some places.