Exception transparency

Peter Levart peter.levart at gmail.com
Thu Jun 10 14:41:36 PDT 2010


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


More information about the lambda-dev mailing list