Exception transparency

[Brian Goetz]

Summary: Patience, Grasshopper.  All of this will come in due time.

> You describe a syntax for declaring these new kinds of type parameters,
> but no syntax for the use site.  The one-type case is familiar, and you
> make two suggestions for the no-type case, but what about the
> two-or-more case (e.g. "IOException or SQLException")?  What about
> disjunctive bounds (they arise in APIs once you start using these type
> parameters).

The disjunctive syntax (A|B) is the likely front-runner here.

> 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.

Similarly we could go down the route of explicitly variadic type parameters 
(identified say by T... or T*).  And the only place you could use them would 
be ... throws and maybe catch clauses, since those are the only places in the 
language where you can put a list of types.

> I conjecture that a new syntax may not be needed at the use site either,
> or at least not frequently.

Likely true.  There is a balance to be struck.  On the one hand, new syntax 
means something new to learn.  On the other hand, shoehorning new semantics 
into existing syntax means likely surprises.  While it can probably be done 
with minimal new syntax, this may not be the best thing for the language or 
the community.

The choice of "throws" or similar at the declaration site and nothing at the 
use site is probably a reasonable balance, but as always: syntax choices to be 
made last.

> How do these new type parameters interact with wildcards?  Can they be
> used in function types?  What are the subtyping rules?

To be provided.

> You suggest that inference will frequently provide these type
> parameters, but there is no provision for that in any of the draft
> specifications for project lambda.

To be provided.

> Your suggestion that a type parameter may be used in a catch blocks and
> is treated as the erasure will be very confusing, and depending on
> precisely what you mean it might undermine exception checking.  Can you
> please explain what motivated you to add that?  Are you hoping that the
> interaction with final type parameters may allow intercepting exceptions
> even when the exception type is a formal generic parameter?

The use in catch blocks is an optional element of this proposal, one that may 
well turn out in the end to be confusing or unworkable.  But the desirability 
of such a feature should be obvious.  We plan to explore it.