Exception transparency

[Peter Levart]

On 06/08/10, Brian Goetz wrote:
> On 06/08/10, Neal Gafter wrote:
> > I conjecture that a new syntax may not be needed at the declaration site
> > at all; it can be inferred from the explicit bound on the type parameter
> > instead of vice-versa, simplifying the syntax and making it more
> > familiar.  Specifically, you can treat any type parameter as a throws
> > type parameter if its bound is Throwable or a subtype.  There is no need
> > to restrict where the type parameter may be used.
> 
> I suspect we might regret that.  When you try to write a class like
>    class ExceptionList<T extends Exception> implements List<T> { ... }
> you'll find that the compiler has guessed your intentions incorrectly.
> 

This is valid today and I don't see any problem with it. Unless you are thinking of this:

class MixedExceptionList<T extends IOException | SQLException> implements List<T> {...}

or this:

static <T extends IOException | SQLException> T catchException(#()(throws T) code) {
    try { code.(); } catch (T e) { return e; }
}

IOException ioe = catchException(#() { new FileInputStream("/etc/passwd").close(); })


...and don't want to introduce disjunctive types as 1st class citizens.

Not introducing disjunctive types as 1st class citizens might be more confusing than introducing them. People might ask why they can catch an exception into a local variable but can't return it's value or assign it to a field. Be prepared for another round of déjà vu: why can't I do new A() where A is a type vaiable...


Regards, Peter