Exception transparency

[maurizio cimadamore]

On 10/06/2010 22:48, Alex Buckley wrote:
> I believe the short answer to this is "yes".
>    
I agree that would work - on the other hand I think that the extra 
'throws' keyword at declaration site is helpful in remembering the 
special nature of this kind of type-variable; as such, using that syntax 
(rather than letting the compiler to figure out everything on its own) 
has its own advantage.

Maurizio
> Alex
>
> On 6/10/2010 2:41 PM, Peter Levart wrote:
>    
>> Hello Maurizio,
>>
>> What if compiler would track internally any type variable with Throwable bound in such a way
>> that when used in any context except "throw" statement it would mean lub(X,Y,Z,...) as defined
>> today but when used in throw statement it would mean X|Y|Z|...
>>
>> 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) throws E {
>>      switch (new Random().nextInt(3)) {
>>        case 0: throw e1;
>>        case 1: throw e2;
>>        default: return new Foo<E>();
>>      }
>>    }
>>
>>    public static void main(String args) {
>>      try {
>>        test(new A(), new B()).set(new Exception());
>>      }
>>      catch (A a) {}
>>      catch (B b) {}
>>    }
>>
>> }
>>
>>
>> Would that work? Would that be back compatible?
>>
>> Regards, Peter
>>
>>
>> On Tuesday, June 08, 2010 02:25:40 pm Maurizio Cimadamore wrote:
>>      
>>> 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
>>>>>>              
>>      
>