在已检查的异常中包装未经检查的异常

Question

Is it advisable as a practice to wrap an Unchecked exception into a Checked exception?

Why this question?

I am creating an API which wraps all the checked exceptions into an API specific checked exception. So I was wondering whether the unchecked exceptions can also be wrapped in checked exception.

Are there any advises on this? If they can be wrapped, it would be great if illustrated with a situation where it can make sense.

Answer 1

Checked exceptions should be used for conditions from which the caller can reasonably be recovered. By throwing a checked exception, you are forcing the caller to handle the exception in a catch clause or to propagate it outward. The API user can be recovered from the exceptional condition by catching the Exception and taking proper recovery steps.

For example, FileNotFoundException is a checked exception :

try {
    FileInputStream fis = new FileInputStream(file);
    } catch (FileNotFoundException e) {
    // HANDLE THE EXCEPTION
}

Here even if the file is not found, continued execution of the application would be possible if the user has proper recovery steps in place (reading the file from a different location, etc.).

On the other hand, Runtime exceptions should be used to indicate that recovery is not possible and continued execution would do more harm. Many a times, runtime exceptions are used to indicate precondition violations: the contract that has been defined to use your API is violated by the client of your API.

For example, ArrayIndexOutOfBoundsException is a runtime exception :

int[] aa = new int[2];
int ii = aa[2]; // java.lang.ArrayIndexOutOfBoundsException

because the contract to access elements of an array says that array index must be between zero and the array length minus one, and we have violated that precondition above.

Again, suppose you are writing a class Address as below where the areaCode cannot be null . And if anybody creates an Address without an areaCode , it might do more harm in the future while using the Address . Here, you can use IllegalArgumentException (which is a runtime exception) to indicate that:

public class Address {
private String areaCode;

public Address(String areaCode) {
    if (areaCode == null) {
        throw new IllegalArgumentException("Area Code cannot be NULL");
    }
    this.areaCode = areaCode;
}
...
}

So, it is advisable to use checked exceptions wherever recovery is possible, and if recovery is not possible or if there is any precondition violation, it is good to use Runtime exception .

Answer 2

One advice: Don't use CheckedExceptions! Always try to let your own Exception inherit from RuntimeException to let the user of your API the choice whether he likes to react to an exception or not!

Here is a blogpost which discribes the issue: http://jandiandme.blogspot.de/2013/05/why-javas-checked-exceptions-are-issue.html

EDIT: Would you please comment your downvote!

Answer 3

I am creating an API which wraps all the checked exceptions into an API specific checked exception.

To achieve this, if you are not explicitly having catch(Runtime e) before catch(Exception e) , you are anyway wrapping unchecked exception too. Which IMO is generally what is being followed unless there is an specific requirement to treat Runtime exception separately.

It's fine for a service to catch both runtime and checked exception to a service level exception sothat caller would deal with only ServiceException which might have custom attributes, codes etc.

One example could be having a service method which works on IO APIs:

public void serviceA(String path) throws ServiceException {
try {
File f = new File(path); //Runtime - NPE etc
Reader r = .. //Checked IOException, may be some Runtime exception
}catch(Exception e) { //both runtime and checked
throw new ServiceException("CUSTOMMSG", e);
}
}

Here, dealing with Runtime exception would be very specific case as service contract is via ServiceException which caller understands and would not know how to deal with Runtime Exception.

Answer 4

@Narendra, Parent class in your API can extend Exception class, so that your API wraps checked and unchecked exception together. Or you can create new API extending RuntimeException to include un-checked exception. I will prefer first option for my implementation to reuse super references where ever required.