Exception transparency

[Ali Lahijani]

Brian,

It might be too soon for a comment from the public, I know the EG is
not yet done with exception transparency.
Anyway, I hope it is not inappropriate.

I currently know of two options for exception transparency. Besides
BGGA-style throws type parameters, there are full blown union types.
But both need changing existing SAM interface definitions to add new
type parameters for the list of exceptions, which has several
drawbacks.

I was thinking if Java could add throws clauses to existing SAM types,
without the SAM type itself being required to declare anything.
Something like Callable<X> throws E1, E2. The definition of Callable
will not be changed and the throws clause here effectively overrides
the original one at Callable.run().

    Callable<X> throws CheckedFooException c = () -> { throw new
CheckedFooException() };

or maybe:
    Callable<X> c throws CheckedFooException = () -> { throw new
CheckedFooException() };

I cannot think of a legitimate reason why a SAM type's definition
might want to categorically prohibit exception transparency. So,
requiring them to state the obvious, that transparency is allowed,
seems redundant.

There is a simple rule of subtyping which the compiler enforces.
Callable<X> throws E_i is assignable from Callable<X> throws E_j iff
any single E_j extends some E_i. There is no cast operator in the
other direction. If you want that, you have to wrap the expression in
a try-catch.

So in particular, Runnable will not be assignable from Runnable throws
Foo, (if the latter is indeed permitted).

A light weight erasure-based approach is to keep just one Class object
for Callable. Additional throws clauses are implemented as an
attribute on types at declaration sites. Possibly even a jsr308 type
annotation like @Throws(CheckedFooException.class) or  @Throws("E1",
"E2") can do. Other possibilities also come to mind here.

Best