Given: Throwable is Exception's superclass.
When I read texts on writing your own 'exceptions', I see examples of Throwable being used in the catch block and other texts show new Exception() being used in the catch block. I have yet to see an explanation of when one should use each.
My question is this, when should Throwable be used and when should new Exception() be used?
Inside the catch or else block using either:
throw throwable;
or
throw new Exception();
Always throw an Exception (never a Throwable). You generally don't catch Throwable either, but you can. Throwable is the superclass to Exception and Error, so you would catch Throwable if you wanted to not only catch Exceptions but Errors, that's the point in having it. The thing is, Errors are generally things which a normal application wouldn't and shouldn't catch, so just use Exception unless you have a specific reason to use Throwable.
(from comments) The issue that brought this up is that I need to pass an 'exception' to a piece of code a coworker is building if a collection does not get built.
In that case, you might want to throw a checked exception. You could throw an Exception, an appropriate existing subclass of it (except RuntimeException and its subclasses which are unchecked), or a custom subclass of Exception (e.g. "CollectionBuildException"). See the Java Tutorial on Exceptions to get up to speed with Java exceptions.
You should not really catch an exception and throw a new one as general as "new Exception".
Instead, if you wish to bubble up the exception just do the following:
try {
// Do some stuff here
}
catch (DivideByZeroException e) {
System.out.println("Can't divide by Zero!");
}
catch (IndexOutOfRangeException e) {
// catch the exception
System.out.println("No matching element found.");
}
catch (Throwable e) {
throw e; // rethrow the exception/error that occurred
}
It is not good practise, I believe, to catch an exception and throw a new exception instead of the one that was raised to your code block, unless you raise a useful custom exception that provides enough context to elude to the cause of the original exception.
Only two places you should see the word Throwable in code:
public static void main(String args[])
{
try
{
// Do some stuff
}
catch(Throwable t)
{
}
}
AND
public class SomeServlet extends HttpServlet
{
public void doPost(HttpRequest request, HttpResponse response)
{
try
{
// Do some stuff
}
catch (Throwable t)
{
// Log
}
}
}
Oracle gives the answer in its official tutorial ("How to Throw Exceptions").
First it explains that Throwables is a union of Error and Exception classes, which are 2 different things.
Next, it makes clear that an Error is something extremely rare, that is almost impossible to recover from.
When a dynamic linking failure or other hard failure in the Java virtual machine occurs, the virtual machine throws an Error.
And putting 1+1 together, it politely concludes, that (except for simple Exceptions) there is no point in catching other Throwables, since you can't do anything about them.
Simple programs typically do not catch or throw Errors.
Throwable is an interface, not a class. Two classes extend Throwable, Exception and Error.
The rule is: be as specific as you can when catching exceptions - that means for example catching Exception instead of Throwable, and IOException instead of Exception.
Don't catch Errors - errors are bugs. Fix the code instead.
If you have to catch absolutely everything, use "catch Throwable", but this is bad form.
throw new Exception(); is something you should never do in a catch block, but you may have to or want to do throw new SomeException(throwable); (preserving the full stack trace) instead of throw throwable; in order to conform to the API of your method, e.g. when it declares to throw SomeException but you're calling code that might throw an IOException that you don't want to add to you method's throws clause.
The probably most common case is new RuntimeException(throwable); to avoid having a throws clause altogether. Many people will tell you this is a horrible abuse because you should be using checked exceptions. IMO they are wrong and checked exceptions are a mistake in the Java language design that just results in ugly, unmaintainable code.
Generally, you would not throw or catch Throwable. In particular, JVM errors (that extend Error() ) are not meant to be caught by user code unless you are doing weird system-level work.
Treat "Throwable" as a language artifact. The "Exception" class is named that because it is the one that is intended to be used by programmers when they want a code block to exit "exceptionally" - by not exiting normally or returning a value.
That includes both regular error situations (by "regular" I mean as opposed to JVM errors) and places where you are using exceptions as a control mechanism.
You shouldn't use Exceptions as a "return type" either...
If the condition you're throwing for is common, you are spending a huge amount of resources to return that condition to the calling routine. Exceptions are expensive to construct.
I've seen cases where tight loops that threw exceptions as a "negative" for e.g. ID allocation, this routine occupied about 99% of the CPU time .. when changed to a documented return constant instead, this dropped to 25%.
As I heard it when java first came out, the theory was that Throwable might be used for transfer of control in other cases besides exceptions. I've never seen it used that way though (and that's probably a Very Good Thing).
So just catch Exception (or better yet, a more fine-grained exception).
Throwable is meant to be only caught by the container or main loop of your program. Most of the time catching stuff below Exception eg Error does not add much capability to a program, after all what can you possible do if a VirtualError other Errors are thrown. Not much except log and continue.
All exceptions are a problem in the end... too say Errors are bugs doesnt mean anything.
Errors are not bugs - they are problems that the host VM is experiencing, eg OutOfMemoryError. Exceptions are a means that the current operation may use to notify that it failed and perhaps provide some diagnosis.