Why can't I have a catch for a checked exception for a call that throws a generic?

Question

I am working on a small helper that is supposed to invoke arbitrary code (passed in as lambda). The helper should catch certain exceptions, and throw them inside some wrapper. My "own" exceptions should not be wrapped but just re-thrown.

I came up with this code:

@FunctionalInterface
interface Processable<T, X extends Throwable> {
    public T apply() throws X;
}

class MyCheckedException extends Exception { ... }
class MyCheckedExceptionWrapper extends MyCheckedException { ... }

public class MyExceptionLogger<T, X extends Throwable> {
    public T process(Processable<T, X> processable) throws MyCheckedException {
        try {
            return processable.apply();
        } catch (MyCheckedException thrown) { // this line isn't accepted
            throw thrown;
        } catch (Exception | LinkageError thrown) {
            throw new MyCheckedExceptionWrapper(thrown);
        } catch (Throwable thrown) {
           ... just log
          return null; 
        }
    }
}

The above gives a compile error:

Unreachable catch block for MyCheckedException. This exception is never thrown from the try statement body MyExceptionLogger ...

In other words: although apply() is defined to throw some X extends Throwable I can't catch a specific checked exception when invoking that method.

I know that I can get to working code by catching Throwable, to then use instanceof checks - but I would like to understand why it is not possible to have a try/catch as outlined above.

Answer 1

This behavior is specified in section 11.2.3 of JLS:

It is a compile-time error if a catch clause can catch checked exception class E1 and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E1, unless E1 is Exception or a superclass of Exception.

MyCheckedException fits the description of E1 class above, because it is not declared in the generic declaration of processable.apply(), and it is not Exception or one of its superclasses. The compiler knows only that the method can throw a Throwable, so MyCheckedException is not declared.

Answer 2

I think there is - based on the JSL - no good reason why you should not be able to catch your custom checked exception in your example.

If you read the cite from the JLS

It is a compile-time error if a catch clause can catch checked exception class E1 and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E1, unless E1 is Exception or a superclass of Exception.

A catch-clause should be allowed to catch any checked Exception, if a method in the corresponding try-block declares Throwable. In your example the try-block can throw a checked exception class that is a subclass or superclass of MyCheckedException namely Throwable and MyCheckedException is obviously not Exception or a superclass of Exception

This can easily be verified by removing the generics from the above example and see it compile without issues:

@FunctionalInterface
interface Processable<T> {
    public T apply() throws Throwable;
}


private <T> T process(Processable<T> aProcessable) {
    try {
        return aProcessable.apply();
    } catch (MyCheckedException e) {
        e.printStackTrace();
    } catch (Exception e) {
        e.printStackTrace();
    } catch (Throwable e) {
        e.printStackTrace();
    }

    return null;
}

That is this problem somehow has to be related to the use of generics in combination with exceptions. Maybe this is related to type erasure, but with erased types your example works fine as well:

@FunctionalInterface
interface Processable {
    public Object apply() throws Throwable;
}


private Object process(Processable aProcessable) {
    try {
        return aProcessable.apply();
    } catch (MyCheckedException e) {
        e.printStackTrace();
    } catch (Exception e) {
        e.printStackTrace();
    } catch (Throwable e) {
        e.printStackTrace();
    }

    return null;
}