Catching and Throwing an Exception: What happens "under the hood"?

Question

I am not familiar with error/exception handling. What is happening "under the hood" when an exception is caught and thrown?

I.e. what is the point of catching an exception in a try-catch block, then throwing it?

E.g:

  try {
        //Stuff
    } catch(StuffException e) {
        throw new MyException();
    }
}

Answer 1

Regarding the inner workings of the exception mechanism: There is plenty of documentation on this. I'm particularly a fan of this article: http://www.javaworld.com/article/2076868/learn-java/how-the-java-virtual-machine-handles-exceptions.html

Ultra-short summary: When an exception is thrown, the jvm looks up in a table where the execution (of the init() method of the exception) continues.

For the second part of your question:

what is the point of catching an exception in a try-catch block, then throwing it?

I see some reasons for catching an exception an throwing another one:

• You might want to catch an unchecked exception (because you know, "something bad might happen") and throw a checked one - so the caller has to handle it.

• You want to use a custom Exception, maybe with additional information/logic

• You're Implementing an error facade, e.g. throwing exceptions and catching them at the end in the facade.

Answer 2

Your example catches something with the type of StuffException, then throws a MyException. This is done to abstract away the original exception; it might be that the original exception is an implementation detail that the thing calling it doesn't need to know about (and which needs to be able to change, so that the caller shouldn't depend on it), and the exception thrown to replace it is part of the published API, which the caller can depend on. This is the case with Hibernate, it catches SQLExceptions generated in the course of calling JDBC functions, and wraps them in Hibernate exceptions, so calling code recognizes them as being thrown from Hibernate, and calling code doesn't depend directly on the JDBC exceptions, but on Hibernate's. If JDBC changed what exceptions it throws then, once Hibernate adapted to it, users of Hibernate wouldn't have to change.

What's bad about this example is that the stacktrace information for the original StuffException gets discarded when e goes out of scope, and MyException's stacktrace starts with the location that threw the MyException, making it difficult to find the source of the actual problem. Assigning the old exception to the new exception as its cause would preserve the original stacktrace information:

try {
        //Stuff
    } catch(StuffException e) {
        MyException myException = new MyException();
        myException.initCause(e);
        throw myException;
    }
}