Is it okay to handle Runtime exceptions?

Question

It's generally a good practice to not handle runtime exceptions.

I have this scenario :

  /**boolean returns false if the method execution fails,
  so that an error can be shown to user*/ 
boolean saveData()
 {
    try
    {
         //Some database calls that throw only Runtime exceptions
     }
     catch(Exception e)
     {
         //Log the exception and return false
         return false;
     }
     return true;

 }

So from the Servlet calling it will get a boolean value. If it's false, we show a message 'Save Not sucessful'. Is this okay or is there a better way of doing it ?

Answer 1

It's generally a good practice to not handle runtime exceptions.

This sentence implies a false premise: the question is not whether, but when to catch runtime exceptions.

At some point in your code you should definitely have a "catch-all" exception handler. This point is called the exception barrier, and it is high enough in the call stack to encompass a complete unit of work (basically, the scope of one database transaction).

This should be your governing principle:

• if an exception must cause the current unit of work to be aborted (rolled back), then do not catch that exception until the exception barrier;

• if an exception is of local character only, and its appearance only means taking a different route to the handling of the request, then do catch and handle it early.

Note that the above doesn't use the fruitless checked/unchecked distinction. Most modern frameworks completely avoid checked exceptions and go out of their way to shield the programmer from such exceptions being thrown from lower-level code.

In practice, more than 90% of all exceptions are of the first, aborting kind. This is what is meant by the term "unrecoverable"—it means you can't continue what you are doing right now, but the server can stay up and process all other requests. I see many people confusing this with "the JVM is about to die", but exceptions which have that meaning are exceedingly rare and usually there is no special handling code for them.

Lastly, note that the "catch-all" handler should catch not only RuntimeExceptions but also Errors because you want every exception logged the same way. If you let an exception escape your application code, there is no knowing what behavior it will cause. Note that there are some common errors, like StackOverflow and OutOfMemory, which can in principle cause unrecoverable damage and therefore rightfully belong to the Error hierarchy, yet in most real-life cases do no damage beyond aborting the current request. You definitely do not want to shut down your service at the first sight of such an error.

Answer 2

boolean returns false if the method execution fails, so that an error can be shown to user

This is a clear reason for the method to throw an exception. It is why the exception mechanism exists in the first place. Best practice is to use exceptions for these types of circumstances, not boolean signals.

Anytime you follow this kind of pattern, you suffer in several ways

• The caller cannot be sure what really happened. Was there a communication failure? Was the data corrupted? There is no way to tell when you return a simple "FAILED" signal.
• Because the caller cannot know what happened, you take away options for the caller. Maybe the caller could do something in certain error cases.
• You increase the potential for data errors. Again, since the caller cannot know why it failed, the caller may make assumptions about why it failed and continue in cases when the entire program should halt. If the program continues, it may decide to process invalid data when it really should stop.

I highly recommend reading the sections on exception handling in Effective Java. Basically, if you can't do anything meaningful with an Exception in your method, you should allow it to pass up the stack. In the worst case scenario, the API you reference throws a generic checked exception, giving you one of three choices (EDIT: Changed to void return type because the boolean return type no longer has any meaning -- you either succeed or throw an exception)

-Create your own.

 // "MyFatalException" would be a checked Exception 
 public void saveData() throws MyFatalException{
        try{
           // ... do stuff that throws Exception
        }catch(Exception e){
           throw new MyFatalException("Unable to save Data due to a general exception"+
                                      " thrown by foo.bar()", e);
        }
 }

-Throw an existing type (my preference is for subclasses of RuntimeException)

public void saveData() throws IllegalStateException{
        try{
           // ... do stuff that throws Exception
        }catch(Exception e){
           throw new IllegalStateException("Unable to save Data due to a general exception"+
                                      " thrown by foo.bar()", e);
        }

-Declare to throw a generic Exception and let it pass up (I do NOT recommend this, but you'll see many developers who do this)

 public void saveData() throws Exception{
       // no try/catch needed.  Just make the call
 }

Answer 3

I guess your question has two aspects: 1) Handling RuntimeExceptionas the heading suggested and 2) handling generic Exception these are two different things.

The Javadoc of RuntimeExcepton list a bunch of its subclasses (NullPointerException..etc). If you look carefully, these are nothing but the programming errors and instead of handling them in catch block, should be corrected the the code itself so that they do not occur.

Handling generic Exception is generally referred as a poor practice and rightly so because it hides the specific exceptions which might need different handling.

But in case similar to yours, if there is a Servlet giving a call to method there has to be a graceful way to tell the user that there was some problem with the application while processing the request instead if showing the stacktrace.

So what you are doing could be one way of handling and as a good practice keep track of errors/exceptions in the log and correct any RuntimeExceptions

Answer 4

In case you try something like this, since you don't want your users to error page you can do this, provided you caught all other exceptions before this.

boolean saveData()
 {
    try
    {
         //Some database calls that throw only Runtime exceptions
     }catch(db_Connectivity_Exception e){
         //exception like credentials invalid
     }catch(db_table_Exception e){
         //table desc. changed
     }
     catch(Exception e)
     {
         //Log the exception and return false
         //Since you are going to log your error I hope is not harmfu
         return false;
     }
     return true;

 }

Still this is not best practice

Answer 5

The general concept is that frameworks or APIs would throw a RuntimeException only in situations when the error is not recoverable in code. e.g: your Db is down, or your server socket is down and things like that. Though its not bad to catch such exceptions but whats actually thoughtful is what do you intend to do after catching them. e.g: people prefer to catch DB level connection problems and errors which are runtime exception subclasses and show error pages on their websites. Checked exceptions are usually for code level situational cases and catching them and handling is what code is expected to do.

Answer 6

Is it okay to handle Runtime exceptions?

As long as you can do something intelligent at that point, yes. This 'never catch run-time exceptions' is pure nonsense. You'll probably want to log them and do other things, as well.

Answer 7

No, catching a general Exception will mask any other problems you don't want to catch. Better catching specific exceptions making it harder for unexpected ones to go missing.