Exception transparency

[Alex Buckley]

On 6/8/2010 6:16 AM, Brian Goetz wrote:
>> It should be possible to write a safe compose:
>>
>> <F, G, H, throws X, throws Y>  Function<F, H, throws X | Y>
>> compose(Function<F, G, X>  fg, Function<? super G, H, Y>  gh);
>>
>> And store the composed function in a variable. For this to work we
>> need to have disjunctive type as a first class citizen (as Peter
>> pointed in a previous message).
> 
> Can you elaborate on why this requires *first-class* disjunctive types?  The 
> signature you write seems perfectly allowable within a framework that allows a 
> disjunction-like entity at the use site of a throws type variable.

I think there are two things going on here:

1) Expression of disjunctive types during inference. I agree with Neal 
that the lub of exception type arguments should produce a disjunctive type.

2) Denotation of disjunctive types. We allow them only in an exception 
type argument "a.m<throws X|Y>(..)", "new Foo<String, throws X|Y>()", 
etc. In particular, not as the bound of an exception type parameter. 
Moreover, exception type parameters "<throws E> void m();" may only be 
used in exception type arguments (and throws clauses), not as "bare" 
types. With these restrictions, exception type arguments are covariant, 
which is nice. Without these restrictions, you could do this:

interface Function<throws E> { void m(E e); }
Function<throws IOException> e = #(IOException e){...};
Function<throws Exception>   f = e;
try { f.(new Exception()); /* Oops */ } catch (Exception ex) {}

(Actually, I guess we could preserve covariant exception type arguments 
by banning exception type parameters from appearing in contravariant 
locations like method parameters.)

Anyway, as Brian said, you can write the safe compose method above, 
since 'throws X | Y' is an exception type argument, and assign its 
result to a Function<..., ..., throws FooExc | BarExc> variable.

Alex