Exception transparency

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Jun 8 03:21:25 PDT 2010


On 08/06/10 11:12, Rémi Forax wrote:
> Le 08/06/2010 08:31, Neal Gafter a écrit :
>    
>> 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.
>>
>>      
> Neal,
> I have trouble to figure out an example of such rare places.
>
> Do you have an example of such code ?
>    
Could be this?

class A<X> extends Exception {}
class B extends A<String> {}
class C extends A<Integer> {}

<throws E> E choose(E e1, E e2) { ... }

choose(new B(), new C()); //what is the inferred type for E???

In JDK 5/6 E is inferred to be A<? extends Object & Comparable<? extends 
Object & Comparable<?>>>. In JDK 7 with the proposed new semantics for 
'exception-bound' type-vars the inferred type would be something like 
A<String> | A<Integer>, which, I guess, would need to be rejected as an 
ill-formed type on the grounds of type-disjointness (A<String> and 
A<Integer> are not provably distinct).

Maurizio
> Rémi
>
>    



More information about the lambda-dev mailing list