Is it good practice to convert RuntimeException to Checked?

Question

I have below class with one method which throws Checked Exception.

public class Sample{

 public String getName() throws DaoException{

  //Some code
   //this method contacts some third party library and that can throw RunTimeExceptions

}

}

DaoException.java

public class DaoException Extends Exception{
 //Some code


}

Now in another class i need to call above the method and handle exceptions.

public String getResult() throws ServiceException{
  try{
  String result = sample.getName();
   //some code
  }catch(Exception e){
     throw new ServiceException(e)
   }
  return result;
}

ServiceException.java

public class ServiceException Extends Exception{
     //Some code


    }

In above catch block, my DAO method can throw DaoException or Any run time exception. But i have single catch block which will catch both and convert them to Checked exception and return.

Is it good practice to convert or should i throw run time exceptions as is?

Thanks!

Answer 1

In most cases RuntimeException being thrown by some library means that the condition occurred cannot be handled such as NullPointerException . So when you will wrap them into Checked exception the client will be forced to handle such exceptions for which there is no point in catching.

So I would say only wrap exceptions if there is some chance of being recovered from some bad situation.

A good use of Checked exceptions:

Many times some operations are timed operations, tryConnection(duration) , when the duration times out then a checked exception can be thrown TimedOutException , now the client can take a decision as to whether a retry is required or not. So this serves the purpose of checked exceptions.

Answer 2

you should clearly separate checked and runtime exception

checked : you are giving client opportunity that this method invocation could result in this exceptional case and you declare that and give client opportunity to handle this properly and give chance to recover

unchecked : you document that this method could throw this runtime exception, and which is generally not recoverable by client, and demonstrate program or infrastructure exceptional condition

if you want to separately catch multiple types of exception you could have multiple catch block

Answer 3

Is it good practice to convert RuntimeException to Checked?

There at two kinds of Java programmers: those who think that checked exceptions are a good thing, and those who think they are a bad thing.

These two groups of programmers would give you opposite Answers to this Question.

My advice would be to weigh up the pros and cons for yourself, and make your own decision in the context of what the application design requires . Since it is impractical for us to review that design, nobody can tell you which path to take ... even if there was an objectively correct path.

---

Having said that, your Question includes an example of a dangerous (IMO) programming practice.

...
} catch (Exception e) {
   throw new ServiceException(e)
}

When you catch Exception , you are catching all possible exceptions (apart from the Error exceptions that you should (almost) never catch anyway). What if the exception you caught was a (say) an NPE caused a bug in your code ... and that you should have allowed to propagate (or logged)? What if it was a checked exception that you could and should have recovered from ... or otherwise dealt with?

Catching Exception often leads to problems / bugs being swept under the carpet ... only to emerge and cause problems down the track.

Answer 4

It really depends on your design. If you want to treat both run time and DAO exceptions similarly, then I think you're doing it right.

Otherwise, if you would like to treat them differently, you can subclass ServiceException into two different exceptions, say for example ServiceUnavailableException and CriticalServiceException.

So it all depends on who will be calling getResult() and what kind of verbosity you would like to offer.

If this was a Service that you're exposing, I would handle RuntimeExceptions. (Many frameworks allow a generic handling mechanism for uncaught exceptions) instead of returning a strange error to the user.

If this was part of a global system, I would not even handle the RuntimeException on this side, as it can mark an exceptional case that requires a fix through code changes in the future.