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