Is it not a good practice to handle runtime exceptions in the code?

Question

I am working on a Java application, and I see that Run time exceptions are handled in many places. For example,

       try {

                  //do something

        }catch(NullPointerException e){

            return null;

       }

My questions is, when is it a good practice to handle Runtime exceptions? When should exceptions be left unhandled?

Answer 1

It depends.

For example, Integer#parseInt throws NumberFormatException (which is a RTE) if the provided string can't be parsed. But surely you don't want your app to crash just because the user wrote "x" to a text field that was for integers? And how do you know whether the string can be parsed, unless you try to parse it first? So in this case, the RTE is just an error signal that should cause some kind of error message. One could argue that it should be a checked exception, but what can you do - it isn't.

Answer 2

NullPointerExceptions are usually the sign of a missing null check. So, instead of catching it like this, you should add the apropriate null check to be sure to not throw the exception.

But sometimes, it is appropiate to handle RunTimeExceptions. For example, when you cannot modify the code to add the null check at the appropriate place, or when the exception is something other than a NullPointerException.

Your example of handling exceptions is terrible. Doing so, you lose the stack trace and precise information about the problem. And you are actually not solving it as you will probably trigger another NullPointerException in a different place, and get misleading information about what happened and how to solve it.

Answer 3

Exceptions should be just that.. exceptions. Best practice when using exceptions is to use them to cover the situation in which something contrary to what you would expect to happen happens. The classic example is the FileNotFoundException which gets thrown when a file simply isn't there. If you're testing the existence of the file, then you use File.exists() since you're simply prodding with a 10 foot stick to see if you hit something.

You could technically accomplish the same results by surrounding it in a try catch and using the file as if it existed, but A) exceptions are generally costly resource-wise and B) programmers are going to assume you meant the file to exist if it was in a try catch, which adds to the overall confusion of a program.

There are many situations in which I'll write a method which fetches some value from a database. A thousand things could go wrong, and seeing how I only need one small piece of information, it's inconvenient to surround the call with a try catch list that contains 5 various exceptions. So, I'll catch exceptions in the fetch method. If something goes wrong, I take whatever appropriate action to close the database connection or whatnot in the finally clause and return null. This is good practice not only because it simplifies your code but also because "null" sends the same message you could have gotten from an exception.. that something didn't go as planned. Manage exception specifics in the fetch method, but manage what to do when things don't go as planned in the receiving end by checking to see if the result was null.

For example:

Integer getUserCount() {
   Integer result = null;
   try {
      // Attempt to open database and retrieve data
   } catch (TimeoutException e) {
      logger.error("Got a watch?");
   } catch (MissingDatabaseException e) {
      logger.error("What are you smoking?");
   } catch (PermissionsToReadException e) {
      logger.error("Did you *really* think you were getting away with that?");
   } catch (PressedSendButtonToHardException e) {
      logger.error("Seriously.. just back away from the computer... slowly..");
   } catch (WTFException e) {
      logger.error("You're on your own with this one.. I don't even know what happened..");
   } finally {
      // Close connections and whatnot
   }
   return result;
}

void doStuff() {
   Integer result = getUserCount();
   if(result != null) {
       // Went as planned..
   }
}

Answer 4

I handle Expected exceptions where I expect them. (Like DB read/write errors). Unexpected exceptions I bubble up. Somewhere else may be expecting the exception and have the logic for it.

Answer 5

yes you are correct handling run time exceptions is not a good practice.The reason is that it is considered to costly/ memory intensive.