When is it OK to catch a RuntimeException

Question

On a recent project I recommended catching a RuntimeException within a test harness code and logging it. The code processes a series of inputs from a database, and I do not

Answer 1

We all know that checked exceptions and RuntimeExceptions are the two categories of exceptions. It is always suggested that we handle (either try-catch or throw) the checked exceptions because they are the programming conditions where unfortunately programmer can not to do anything on its own; Like FileNotFoundException it is not the programmer who puts files on user's drive if program is actually trying to read the file 1.txt which is supposed to be there on f:\ of user with the statements:

File f11 = new File("f:\\1.txt");
FileInputStream fos = new FileInputStream(f11);

If the file is found it's all ok, but what happens in the other case if the file is not found is that, program crashes down with 0 error from the user. In this scenario programmer did not do anything wrong. This could be a checked exception which must be caught for the program to continue running.

Let me also explain the second scenario with which the concept of RuntimeException will be clear. Consider following code:

int a = {1,2,3,4,5};
System.out.println(a[9]);

This is poor coding which generates the ArrayIndexOutOfBoundsException. Which is an example of RuntimeException. So programmer should not actually handle the exception, let it crash the program, and later fix the logic.

Answer 2

RuntimeException is intended to be used for programmer errors. As such it should never be caught. There are a few cases where it should be:

1. you are calling code that comes from a 3rd party where you do not have control over when they throw exception. I would argue that you should do this on a case by case basis and wrap the usage of the 3rd party code within your own classes so you can pass back non-runtime exceptions.

2. your program cannot crash and leave a stack trace for the user to see. In this case it should go around main and around any threads and event handling code. The program should probably exit when such exception occurs as well.

In your specific case I would have to question why you are having RuntimeExceptions occur in the tests - you should be fixing them instead of working around them.

So you should guarantee that your code only throws RuntimeExceptions when you want to have the program exit. You should only catch RuntimeExceptions when you want to log it and exit. That is what is in line with the intent of RuntimeExceptions.

You can look at this discussion for some other reasons that people give... I personally haven't found a compelling reason in the answers though.

Answer 3

You catch RuntimeException when you want to process it. Maybe you want to rethrow it as a different exception or log it to a file or database, or you want to turn on some exception flag in the return type, etc.

Answer 4

Unless you can correct a RuntimeException, you don't want to catch it...

...only true from a developers point of view....

you have to catch all exceptions before they reach up to the UI and make your user sad. This means on the "highest level" you want to catch anything that happend further down. Then you can let the user know there was a problem and at the same time take measures to inform the developers, like sending out alarm mails or whatever...

It is basically considered a data/programming error that could not be forseen, thus you want to improve future releases of the software while at the same time take the user by the hand and move on in a controlled manner...

Answer 5

You catch RuntimeException for the same reason that you catch any exception: You plan to do something with it. Perhaps you can correct whatever caused the exception. Perhaps you simply want to re-throw with a different exception type.

Catching and ignoring any exception, however, is extremely bad practice.

Answer 6

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.

Here's the bottom line guideline.

From Java Docs. Please read this Unchecked Exceptions — The Controversy