Runtime Vs. Checked Exceptions

skull5Java is strange, in that it makes a distinction between runtime exceptions (which don’t need to be declared, and can bubble all the way up to the top of the stack), and checked exceptions, which need to be either wrapped in a “try-catch” block, or declared in the method signature so that the calling method will have to deal with them.

If you know Java, then you know this (or should -it’s one of the standard phone interview questions to weed out the fakes). But do you know why this distinction exists? Or when one type should be used and not another? A lot of developers don’t; if you do, then you are at an advantage, especially in jobs where architecting core Java is required.

Let me start out by saying that this distinction is controversial, and a lot of developers say it is unnecessary; I on the other hand like it, as I think it is an elegant way of enforcing the contract between your code and the code that might call it.

But first, the canonical, theoretical answer:

  • A checked exception is an error condition that a program should be able to recover from. Examples of this would be the connection to a downstream server timing out or failing, or resource suddenly becoming unavailable. All these cases should in theory be able to be handled either by your code or by the calling code (I’ll get onto this in a bit)
  • A runtime exception is an error condition so bad that the application itself should be considered broken, and that further execution is unviable. Examples of this include NullPointerExceptions (which should never happen in a well constructed program) or ArrayIndexOutOfBoundsExceptions (again, these should never happen). In the event of one of these being thrown, the JVM should terminate as soon as possible to stop further damage being done.

You might not agree with the above definitions, but you should at least know them. Modern frameworks have their own exception handling paradigms, and modern coding involves a lot of gluing different libraries together rather than creating complex Object structures with clear exception handling strategies, so the theoretical underpinnings of Java might not be that important to you in your role. However, if you want to create a well architected, easily usable library or system with more than a few object levels, you might want to bear the above in mind.

So, assuming you’ve drunk the kool-aid and want to up your exception game, what should you do? Here are some tips

  • Work mainly with checked exceptions. Never do ‘new RuntimeException (“my problem here”)’ unless a condition occurs where the program itself is broken (it is rare that you’d have to do this; most of these conditions are covered by Java’s own set of runtime exceptions and the JVM).
  • Whenever you are calling a method that throws a checked exception, ask yourself whether your code should handle the problem, or the code calling your method. Generally it boils down to ‘who makes the decision what to do about this, this method or the method calling it?’
    • For example, your class might be a database utility class that calls a JDBC driver; if the query times out and throws an exception, you might want your code to retry the query a few times, in which case you would handle it so you’d add a try-catch block.
    • If, following on from the above example, the query still kept timing out, then you’d want to throw a new (checked) checked exception back up the stack to the calling code (or rethrow the original), so that it can decide what to do with this query that can’t be run.
    • Another example, if your class was a file system utility class for an application that allowed users to upload files, and it was calling File object methods that throw IOExceptions when the disk is full, you might want to pass those exceptions up the stack to the calling code so that it can decide what to tell the end user, or whether or not to retry with a different form of storage such as cloud.
  • Remember that runtime exceptions extend the RuntimeException class; everything else is checked.

So those are my thoughts on Java exception handling. Let me know yours in the comments section below!


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s