Should unchecked exceptions be caught and dealt with?

Question

I have been reading many posts about exceptions lately and I have a question whether unchecked exceptions should be caught. I have read that if you want your application to

Answer 1

Should unchecked exceptions be caught and dealt with?

The answer is that it depends:

• It depends on what the exception is.

• It depends on why the exception was thrown. Was it "expected"? Was it due to a bug, or bad input, or an environmental problem? Or something else?

• It depends if there is a good way to recover. That typically depends in part on the previous criteria.

If the exception is unexpected, the cause of the exception is uncertain, and / or if there is no sound recovery strategy if you do catch the exception, then it is generally better to allow the exception to bubble up, and make sure that it gets reported / logged at the top level.

And if the exception is an Error, the general rule is that you should NOT attempt to recover. And that includes StackOverflowError and (particularly) OutOfMemoryError. The Error exceptions indicate a problem that is difficult (or impossible) to safely recover from, and the best strategy is to allow or cause the application to exit.

---

What do you mean by reported/logged at the top level? Do you mean catching it at the UI layer for instance and show an dialog, log it etc?

I mean that the exception and its stack trace should be written to the application's log file so that the evidence of the problem is available for the maintainers to look at. Whether you also try to explain the problem to the end user (and how you do that) is a separate issue.

The "top level" may be the "main" method, a child thread or runnable's "run" method ... or an uncaught exception handler. Basically it is wherever the exception eventually will "bubble up" to if it is not caught. Details will depend on your application's architecture.

Answer 2

Nothing forbids you from catching runtime exceptions.

The trend, nowadays, is to use more and more runtime exceptions, and less and less checked exceptions. Spring, Hibernate, and the latest Java EE specs use runtime exceptions almost exclusively. This makes the business code easier to read and less cumbersome.

The runtime exceptions are generally intended to be not caught at all, or only caught at the bottom of the call stack, in the UI layer, in order to display an error message, because that's usually the only thing you can do when such an exception occurs.

Answer 3

The basic difference between the Checked and Unchecked Exception is that, you need to explicitly handle the former or propagate it in the inheritance hierarchy, while this is not required for the later.

Also, CheckedException extend from java.lang.Exception, while UncheckedExceptions extend from java.lang.RuntimeException, which are not needed to be handled. Note that, RuntimeException are themselves a subclass of Exception.

Given, all the information above, if you handle an unchecked exception then its fine. It will work fine, and the control will go to the corresponding catch block. But you shouldn't do it. Unless, you really need it and you have a proper way to handle them.

• For e.g: - You should handle an IllegalArgumentException which is an Unchecked Exception.

• And then, you shouldn't handle errors like: - StackOverflowError. As, you don't know why that problem might have occurred, and what could be an appropriate way to handle it. So, just leave it to the JVM. Errors are Unchecked Exception that you cannot recover from.

For more details, refer these links: -

• http://tutorials.jenkov.com/java-exception-handling/checked-or-unchecked-exceptions.html
• http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Answer 4

You should catch an exception — checked or unchecked — if you can handle it in a meaningful way to recover from the problem. You generally should not catch an exception if you don't have a good way to handle it.

I've seen too much code that "handles" exceptions by doing e.printStackTrace() and then continuing as if nothing was wrong. Ignoring a problem like that usually just leads to other problems later.

Answer 5

should you catch unchecked exceptions?

Yes and No. Depends on what exception is thrown.

Are unchecked exceptions ideally programming errors that you don't check for?

You can write a catch block to catch unchecked exception but again depends whether you should. If you do then it's possible that a bug remain unsolved for a long time and by the time it is discovered it's size is also changed.

Should they just bubble up from your application?

If they occur, try to solve their cause (if it' spossible). Don't catch them always as Hard and Fast rule.

Answer 6

Choice for checked exceptions is usually: you just add it to throws if you can't do anything about it, catch and convert it to new exception with original as the cause if you can't do anything useful about it but can add information, and catch it and do something about it if it is feasible and also the right place in your code to do something about it.

Unchecked exceptions are a bit more tricky. In the ideal world, they should indicate programming/logic errors, and be handled pretty much like assertion failure, not caught and especially not swallowed.

Some unchecked exception coming from Java standard library or other libraries should in my opinion really be checked exceptions, but are not. These are cases, where the caller should acknowledge that such exceptions may be passing through them even if they don't catch them. For unchecked exceptions that could as well be checked exceptions, basically same rules: catch them if you want to do something about them, otherwise let them bubble up. If you are making a library (even if it's just internal to an application), and an unchecked exception really is something which should be caught later, then you may want to catch and re-throw it wrapped into a checked exception in the library code.

In general, try to avoid having unchecked exceptions thrown. Check the input, so you don't need to catch, and if exception is still thrown, then it's a bug and should be left uncaught. Only catch them if it is the only or at least clearly the best way.

To be fair to Java libraries, the language was designed in the era, when IDEs didn't yet immediately complain about missing throws clauses and offer to fill them in automatically, so making them unchecked may have been justified by reducing burden on developer. But with modern tools, there's really no excuse.

And then, as mentioned in other answers, there are unchecked exceptions you should not catch.