Order of catching exceptions in Java
The order is whatever matches first, gets executed (as the JLS clearly explains).
If the first catch matches the exception, it executes, if it doesn't, the next one is tried and on and on until one is matched or none are.
So, when catching exceptions you want to always catch the most specific first and then the most generic (as RuntimeException or Exception). For instance, imagine you would like to catch the StringIndexOutOfBoundsException thrown by the String.charAt(index) method but your code could also throw a NullPointerException, here's how you could go to catch the exceptions:
String s = null;
try {
s.charAt(10);
} catch ( NullPointerExeption e ) {
System.out.println("null");
e.printStackTrace();
} catch ( StringIndexOutOfBoundsException e ) {
System.out.println("String index error!");
e.printStackTrace();
} catch ( RuntimeException e ) {
System.out.println("runtime exception!");
e.printStackTrace();
}
So, with this order, I am making sure the exceptions are caught correctly and they are not tripping over one another, if it's a NullPointerException it enters the first catch, if a StringIndexOutOfBoundsException it enters the second and finally if it is something else that is a RuntimeException (or inherits from it, like a IllegalArgumentException) it enters the third catch.
Your case is correct as IOException inherits from Exception and RuntimeException also inherits from Exception, so they will not trip over one another.
It's also a compilation error to catch a generic exception first and then one of it's descendants later, as in:
try {
// some code here
} catch ( Exception e) {
e.printStackTrace();
} catch ( RuntimeException e ) { // this line will cause a compilation error because it would never be executed since the first catch would pick the exception
e.printStackTrace();
}
So, you should have the children first and then the parent exceptions.
Is this order a correct one? Or is it correct but a bad option?
Neither. As other answers have said, the compiler should tell you if you put simple catches in an order where one masks another.
But there is another potential issue in your code: should you actually be catching RuntimeException
at all. The issue is that there are many sources / causes of uunchecked exceptions, and many of those sources / causes are actually bugs in your application.
Using the catch
to log a diagnostic as part of an emergency shutdown is fine, but
if you catch and attempt to recover from RuntimeException
, you need to be careful that you are not sweeping a serious problem under the carpet:
Make sure that you log the exception and its stacktrace, no matter what.
Consider whether is is wise to attempt to recover. If you've got an unknown bug, it could have done unpredictable damage before triggering the exception. You've no way of knowing whether the application can recover, or whether it might do worse damage by attempting to continue.
The same advice applies to catching Exception
and Throwable
/ Error
. And it is more critical with Throwable
/ Error
because of the nature of the damage that could well have already occurred.