Re-throwing RuntimeExceptions after catching Checked Exceptions

Question

In Java it is observed that there is a convention of re-throwing a RuntimeException just after handling a Checked Exception.

This way has both good and bad consequences. When the compiler forces something to be handled via a Checked Exception, the developer can just get rid of it by catching it and re-throwing it as a RuntimeException.

Can someone explain if this scenario can be considered as a good practice? If so, would this approach be less error prone or would it make the code base unstable?

Answer 1

Actually it is the incompetent attempts at handling checked exceptions which result in an unstable code base. Typically, you'll have this:

try {
   //stuff
} catch (IOException e) {
   log.error("Failed to do stuff", e);
   throw e;
}

and then next level up you'll have to deal with it again, typically logging it all over and making a mess of the log files. It will be even worse if you don't rethrow:

try {
   // do stuff
} catch (IOException e) {
  return null;
}

Now the calling code has no idea something went wrong, let alone what. Compared to those attempts, this actually accomplishes exactly what the application logic needs:

try {
  // do stuff
} catch (IOException e) {
  throw new RuntimeException(e);
}

Now the exception can freely propagate up the call stack until it reaches the well-defined exception barrier, where it:

1. aborts the current unit of work;
2. gets logged at a single, unified spot.

In a nutshell, to decide whether to catch-and-handle or catch-and-rethrow, just ask yourself this question:

Must the occurrence of this exception abort the current unit of work?

• if yes: rethrow an unchecked exception;
• if no: provide meaningful recovery code in the catch-block. (No, logging is not recovery).

From many years of real-life experience I can tell you that more than 90% of all possible checked exceptions are of the "aborting" type and need no handling at the place of occurrence.

Argument against the language feature of checked exceptions

Today, checked exceptions are widely recognized as a failed experiment in language design, and here's the key argument in a nutshell:

It is not up to the API creator to decide on the semantics of its exceptions in the client code.

Java's reasoning is that exceptions can be divided into

1. exceptions resulting from programming errors (unchecked);
2. exceptions due to circumstances outside of programmer's control (checked).

While this division may be real to some extent, it can be defined only from the perspective of client code. More to the point, it is not a very relevant division in practice: what truly matters is at what point the exception must be handled. If it is to be handled late, at the exception barrier, nothing is gained by the exception being checked. If handled early, then only sometimes there is a mild gain from checked exceptions.

Practice has confirmed that any gains afforded by checked exceptions are dwarfed by real-life damage done to real-life projects, as witnessed by every Java professional. Eclipse and other IDEs are to blame as well, suggesting inexperienced developers to wrap code in try-catch and then wonder what to write in the catch-block.

Whenever you encounter a method which throws Exception, you have found yet another living proof of the deficiency of checked exceptions.

Answer 2

The idea of checked exceptions is "Java only" - as far as I know, no language after Java adopted this idea.

There are too many checked exceptions which are caught ... and silently ignored.

If you look at Scala, they dropped it as well - it's only there for Java compatibility.

In this tutorial on Oracle's web site, you will find this definition:

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.

This notion has been adopted in Scala as well, and it works fine.

Technically speaking your proposal works. Discipline and code reviews are required in either way.

Answer 3

The term "can just get rid of it" is not totally correct in this case. This is getting rid of exceptions:

 try {

 } catch (Exception e){
     e.printStacktrace();
 } 

This is the most common bad practice among the try-catch use. You are catching the exception and then, just printing it. In this case, the catch block catches the exception and just prints it, while the program continues after the catch block, as if nothing had happened.

When you decide to catch a block instead of throwing an exception, you must be able to manage the exception. Sometimes exceptions are not manageable and they must be thrown.

This is something you should remember:

If the client can take some alternate action to recover from the exception, make it a checked exception. If the client cannot do anything useful, then make the exception unchecked. By useful, I mean taking steps to recover from the exception and not just logging the exception.

If you are not going to do something useful, then don't catch the exception. Re-throwing it as a RuntimeException has a reason: as stated before, the program just cannot continue as nothing happened. This way, a good practice would be:

try {

} catch (Exception e){
    //try to do something useful  
    throw new RuntimeException(e); 
}

This means: you just caught an Exception (like an SQLException) from which you can't recover without stopping and resetting the thread. You catch it, you try to make something in between (like resetting something, closing open sockets, etc...) and then you throw a RuntimeException().

The RuntimeException will suspend the whole thread, avoiding the program continue as if nothing have happened. Furthermore, you were able to manage the other exception without just printing it.

Answer 4

It may or may not be okay, depending on the context, but it probably is not.

As a rule of thumb RuntimeExceptions should only be used to indicate programming errors (examples include IllegalArgumentException and IllegalStateException). They don't have to be checked exceptions because you generally assume your program is correct until proven otherwise and you cannot handle these exceptions in a meaningful manner (you have to release an updated version of the program).

Another valid use of runtime exceptions is when you use a framework that will catch and handle the exception for you. In such a scenario it would only be burdensome to having to declare the exception in every method when you are not going to handle it anyway.

So generally speaking I would say re-throwing a checked exception as a runtime exception is very bad practice unless you have a framework that will handle it properly.

Answer 5

The general rule is: you throw a checked exception when the caller might be able to do some kind of recovery when informed about it. Otherwise, throw an unchecked exception.

This rule applies when an exception is first thrown.

But this also applies when you catch an exception and are wondering whether to throw a checked or unchecked exception. So there is no convention to throw a RunTimeException after catching a checked one. It is decided in a case-by-case basis.

One small tip: if you are going to just re-throw an checked exception after catching one and do nothing else, most of the time it is alright to just not catch the exception and add it to the exceptions thrown by the method.