Is it good practice to catch a checked exception and throw a RuntimeException?

Question

I read some code of a colleague and found that he often catches various exceptions and then always throws a 'RuntimeException' instead. I always thought this is very bad practice. Am I wrong?

Answer 1

No, you are not wrong. His practice is extremely misguided. You should throw an exception that captures the issue that caused it. RunTimeException is broad and over reaching. It should be a NullPointerException, ArgumentException, etc. Whatever accurately describes what went wrong. This provides the ability to differentiate issues that you should handle and let the program survive versus errors that should be a "Do not pass go" scenario. What he is doing is only slightly better than "On Error Resume Next" unless there is something missing in the info provided in the question.

Answer 2

I do not know enough context to know whether your colleague is doing something incorrectly or not, so I am going to argue about this in a general sense.

I do not think it is always an incorrect practice to turn checked exceptions into some flavor of runtime exception. Checked exceptions are often misused and abused by developers.

It is very easy to use checked exceptions when they are not meant to be used (unrecoverable conditions, or even control flow). Especially if a checked exception is used for conditions from which the caller cannot recover, I think it is justified to turn that exception to a runtime exception with a helpful message/state. Unfortunately in many cases when one is faced with an unrecoverable condition, they tend to have an empty catch block which is one of the worst things you can do. Debugging such an issue is one of the biggest pains a developer can encounter.

So if you think that you are dealing with a recoverable condition, it should be handled accordingly and the exception should not be turned into a runtime exception. If a checked exception is used for unrecoverable conditions, turning it into a runtime exception is justified.

Answer 3

It can be GOOD. Please read:

http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html

Most of the time, client code cannot do anything about SQLExceptions. Do not hesitate to convert them into unchecked exceptions. Consider the following piece of code:

public void dataAccessCode(){
  try{
      ..some code that throws SQLException
  }catch(SQLException ex){
      ex.printStacktrace();
  }
} 

This catch block just suppresses the exception and does nothing. The justification is that there is nothing my client could do about an SQLException. How about dealing with it in the following manner?

public void dataAccessCode(){
   try{
       ..some code that throws SQLException
   }catch(SQLException ex){
       throw new RuntimeException(ex);
   }
} 

This converts SQLException to RuntimeException. If SQLException occurs, the catch clause throws a new RuntimeException. The execution thread is suspended and the exception gets reported. However, I am not corrupting my business object layer with unnecessary exception handling, especially since it cannot do anything about an SQLException. If my catch needs the root exception cause, I can make use of the getCause() method available in all exception classes as of JDK1.4.

Throwing checked exceptions and not being able to recover from it is not helping.

Some people even think that checked exceptions should not be used at all. See http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html

Recently, several well-regarded experts, including Bruce Eckel and Rod Johnson, have publicly stated that while they initially agreed completely with the orthodox position on checked exceptions, they've concluded that exclusive use of checked exceptions is not as good an idea as it appeared at first, and that checked exceptions have become a significant source of problems for many large projects. Eckel takes a more extreme view, suggesting that all exceptions should be unchecked; Johnson's view is more conservative, but still suggests that the orthodox preference for checked exceptions is excessive. (It's worth noting that the architects of C#, who almost certainly had plenty of experience using Java technology, chose to omit checked exceptions from the language design, making all exceptions unchecked exceptions. They did, however, leave room for an implementation of checked exceptions at a later time.)

Also from the same link:

The decision to use unchecked exceptions is a complicated one, and it's clear that there's no obvious answer. The Sun advice is to use them for nothing, the C# approach (which Eckel and others agree with) is to use them for everything. Others say, "there's a middle ground."

Answer 4

I would like to get comments on this, but I find there are times when this isn't necessarily bad practice. (Or terribly bad). But maybe i am wrong.

Often times an API you are using will throw an exception that you can't imagine actually being thrown in your specific usecase. In this case, it seems perfectly fine to throw a RuntimeException with the caught exception as the cause. If this exception is thrown, it'll likely be the cause of programming error and isn't inside the bounds for correct specification.

Assuming the RuntimeException isn't later caught and ignored, it's no where near an OnErrorResumeNext.

The OnErrorResumeNext would occur when someone catches an exception and simply ignores it or just prints it out. This is terribly bad practice in almost all cases.

Answer 5

It depends.

This practice may be even wise. There are many situations (for example in web developement), where if some exception happens, you are unable to do anything (because you cannot for example repair inconsistent DB from your code :-), only developer can do it). In these situations, it is wise to wrap the thrown exception into a runtime exception a rethrow it. Than you can catch all these exceptions in some exception handling layer, log the error and display the user some nice localized error code + message.

On the other hand, if the exception is not runtime (is checked), the developer of the API indicates, that this exception is resolvable and should be repaired. If its possible, than you should definitely do it.

The other solution might be to rethrow this checked exception into the calling layer, but if you were unable to solve it, where the exception occured, you will be likely unable to solve it here also...

Answer 6

For standalone applications. When you know your application cannot handle the exception you could, instead of throwing the checked RuntimeException, throw Error, let the application crash, hope for bug-reports, and fix your application. (See the answer of mrmuggles for a more in depth discussion of the pro's and con's of checked versus unchecked.)

Answer 7

This might depend on case to case basis. In certain scenarios it is wise to do what your friend is doing, for example when you are exposing an api for some clients and you want the client to be least aware of the implementation details, where you know that certain implementation exceptions may be specific to implementation details and not exposable to the client.

By keeping the checked exceptions out of the way, you can expose api's that would enable the client to write cleaner code as the client itself might be pre-validating the exceptional conditions.

For example Integer.parseInt(String) takes a string and returns the integer equivalent of it and throws NumberFormatException in case the string is not numeric. Now imagine a form submission with a field age is converted through this method but the client would have already ensured validation on its part, so there's no point forcing the check of exception.

Answer 8

This is common practice in many frameworks. E.g. Hibernate does exactly this. The idea is that the APIs should not be intrusive for client side and Exception are intrusive since you must explicitly write code to handle them at that place where you call the api. But that place might not be the right place to handle the exception in the first place.
Actually to be honest this is a "hot" topic and many dispute so I will not take a side but I will say that what your friend does/proposes is not un-ordinary or uncommon.

Answer 9

In my opinion,

In the framework level, we should be catch runtime exceptions to reduce more block of try catch to the invoker in the same place.

In the application level, we rarely capture runtime exceptions and i think this practice was bad.