Is checking for exceptions in code or using try-catch a better practice in Java?

Question

I had someone mention to me that catching all exceptions is not necessarily good practice (for example, NullPointerException). I am looking for an explanation of when this is a good thing, when it is not, and why it is as such :D

Thanks!!

badPanda

Answer 1

In short:

Checked exceptions are for catching

Unchecked exceptions and errors can be left to bubble up. (these are the subclasses of RuntimeException and Error).

This is because checked exceptions are "expected" and the program can recover from them. Unchecked exceptions are such from which the program cannot recover (easily).

Sun's tutorial says (it's about deciding what kind of exception you should create, but it is also informative on the other side - i.e. when using exceptions):

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

Answer 2

And adding to bozho's answer, it sometimes depends on the type of application as well, as you in some case you may have to handle it to perform some work around for that, and in some case you can leave it to handle by the caller or ultimately to terminate.

Answer 3

To further Bozho's post checked exceptions typically handle exceptions you expect to happen regardless of how perfect your code is (ie: a network cable is unplugged and you catch and IO exception). You declare they methods throw checked exceptions as other code must deal with how to handle these exceptions.

Unchecked exceptions tend to be used for unexpected conditions for example NullPointerExceptions often bubble up because the program should have thrown a checked exception, filtered data, set defaults, etc. They are unchecked and often unexpected, thus you do not have to catch them.

This is not true 100% of the time but as a general approach that is how it works, in Java especially.

Answer 4

Exceptions that are not caused by programming errors and/or can be recovered from should be caught. Others should not be. In java generally checked exceptions are supposed to be caught while RunTimeExceptions and Errors are not.

A null pointer exception is caused by a programming error i.e. missing null check so it should not be caught. However there might also be situations where you will want to catch a RunTimeException solely for the purpose of logging it before throwing it back.

Answer 5

The title of your question seems to ask if it's better to check for and handle error conditions in the code or if it's better to just put it all in a try block and deal with exceptions in a catch.

If it's simple, definitely check for an error and deal with it rather than using a try-catch. For example, if you can deal with invalid input by checking it and printing a "please try again" type of message, you wouldn't use a try-catch.

I like to think this way: If I can neatly step around the error introduced by the exception, check for the conditions that would cause it and deal with them. If you wouldn't be able to either easily check for the conditions or easily deal with them, use a try-catch to handle it.

Answer 6

RuntimeExceptions can (most of the cases) be considered "programming errors". For example, think of poping an object from a stack before checking if it actually contains any elements. In a proper implementation, there should be some isEmpty() method given to check the state of the stack. If the programmer is to lazy or forgets to check the stack, an exception should be thrown to indicate a programming error.

These kinds of exceptions should NOT be caught. The idea is to crash the program and inform the programmer of his mistake.

Checked exceptions on the other hand, as others have stated, are exceptions from which the programs is expected to recover from. While this sounds like a good idea in practice, checked exceptions are often thrown when you can't really do anything to solve the cause of the exception. So you end up with lots of boilerplate code (i.e. try-catch-blocks, whose exception blocks do nothing but logging or printing the cause of the exception). Afaik, no newer programming language supports checked exceptions because of this (even JavaFX).

Answer 7

I always implement a try...catch(Throwable) (a Throwable is truly an error and your application should not perform any further operations after it get one of those) at ONE point in my code, when it is extremely important to know what happened so it can be logged. That place is usually the main method.

I also have try...catch(Exception) in a runnable class, or a class that process, for example, one record that can be processed independently of others. In that case, the application should move on even if part of its processing fail - it doesn't matter if I know what exception is going to be thrown or not - I catch the exception, I log it, I abort that processing entry, and I move on.

The rule of thumb is that you should catch an exception if you are going to do something about it (either abort the processing of something, run an alternative routine, or move on, as long as you know what you are doing), if you are not going to do something about it, don't catch it.

And don't use your IDE try...catch creator to hide your exception, instead let it add the exceptions to the method signature.