Exception transparency

[Neal Gafter]

On Mon, Jun 7, 2010 at 5:08 PM, Brian Goetz <brian.goetz at oracle.com> 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.
>

The only place where it makes a difference (assuming BGGA is followed for
exception transparency) is in the application of the lub() operation during
type inference.  The influence of that operation is actually rare in places
where it would make a difference.  In short, I don't think the compiler
needs to guess any intentions where it will affect realistic code.

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.


Once you start spelling out the rules, I think you'll find that it is an
error to think of these as variadic lists of types.  (You can have lists of
types in the bounds of type parameters)


>  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 only place where I'm suggesting changed semantics for existing syntax is
in the meaning of lub() during inference of formal type parameters.
Currently, the result is a conjunctive type.  As I propose, it would be a
disjunctive type if the parameter is bounded by Throwable or a subtype.  I
don't believe there are any realistic programs in existence that can tell
the difference.