Exception transparency

[Maurizio Cimadamore]

On 08/06/10 13:13, Maurizio Cimadamore wrote:
> On 08/06/10 12:54, Peter Levart wrote:
>    
>> On 06/08/10, Maurizio Cimadamore wrote:
>>
>>      
>>>>> 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).
>>>
>>>        
>> Are you suggesting to relax the rule that generic classes can not extend Throwable?
>>
>>      
> Good catch - my example is illegal; no incompatibility here.
>    
I tried harder ;-) :

class Foo<X> { void set(X x) {} }

class A extends Exception {}
class B extends Exception {}

class Test {
    static <E extends Exception> Foo<E> test(E e1, E e2){ return new 
Foo<E>(); }

    public static void main(String args) {
       test(new A(), new B()).set(new Exception());
    }
}

This compiles in JDK 5/6 (E inferred to be Exception); it fails to 
compile under JDK 7 if we assume that type-variables with Exception 
bound have a 'varadic' semantics; in fact in this case the type A|B 
would be inferred. But this means that you cannot pass an Exception 
where an A|B is expected.

Maurizio

> Maurizio
>    
>> Peter
>>
>>
>>      
>>> Maurizio
>>>
>>>
>>>        
>
>