Java: Catching an Exception whose super-type is in the throws list

Question

I've occasionally written Java code in the following manner:

public static TrustManager[] getTrustManagers(TruststoreParams tsParams)
throws IOException, GeneralSecurityException {
    TrustManagerFactory tmf = null;
    FileInputStream fis = null;
    try {
        ...
        return tmf.getTrustManagers();
    }
    catch (NoSuchAlgorithmException nsae) {
        throw new RuntimeException(nsae);
    }
    finally {
        ...
    }

where I am treating the NoSuchAlgorithmException a bit differently than other security-related exceptions. I am wondering if there is anything fundamentally wrong with the exception handling approach above where I have the GeneralSecurityException super-type in the throws list, but I am specifically catching and handling one of its sub-types and wrapping it as a RuntimeException.

How would you rewrite the above method skeleton, if differently than how I have it setup above, and why?

Answer 1

It looks reasonable to me. By throwing a RuntimeException, you're essentially treating that case as a fatal error, which would make sense if your application requires you to use a particular algorithm.

Answer 2

Catching a more-specific exception than you throw can make sense, in that it's always good to respond to specific cases IF YOU HAVE A SPECIFIC RESPONSE. In this case, though, why wrap it in a RuntimeException? Is it a worse case than GeneralSecurityException, i.e. it's so bad you want to bypass the usual handling by the caller? A different GeneralSecurityException wouldn't be as bad?

My approach has changed over the years. Lately I declare a lot fewer exceptions, typically just ones that the caller CAN programmatically deal with, mostly business-related (e.g. NoSuchUser). "System" or infrastructure issues get put into a RuntimeException of some variety, since the caller really can't do anything but bail out on.

In your case, is there anything the caller could do with the IOException or the GeneralSecurityException? If not, I wouldn't put them in the signature at all (it only confuses things for the caller) and just wrap any exceptions that occur in a RuntimeException.

Answer 3

I think that if one of the methods above is interested in NoSuchAlgorithmException then it should deal with it without further assistance.

I would do something like

 try {
     ...
     trustManager.getTrustmanagers(...);

 } catch (GeneralSecurityException e) {
     if (e instanceof NoSuchAlgorithmException) {
        // do something special 
     } else {
        // do regular error handling
     }
 }

In this case no superfluous structures need to be created which trigger actions over a distance, which I find always confusing when I stumble over them.

I must admit that I prefer RuntimeExceptions over checked exception genrally, but not in this case, since it just adds special cases on top of special cases.