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.