Exception transparency

[Rémi Forax]

Le 09/06/2010 12:06, Maurizio Cimadamore a écrit :
> On 09/06/10 09:23, Maurizio Cimadamore wrote:
>    
>> On 09/06/10 00:44, Neal Gafter wrote:
>>
>>      
>>>>    Function<throws IOException>    e = #(IOException e){...};
>>>>
>>>>          
>> Hi
>> just to be clear, on which basis would you reject the above statement? I
>> guess your argument is that a lambda accepting an argument  of type E
>> cannot be SAM-converted to an interface whose method accepts an argument
>> of type 'throws E' (and, more generally, that E and 'throws E' are not
>> interchangeable). Am I reading correctly?
>>
>>      
> To be clearer, what I mean is, given the following declarations:
>
> class Foo<throws E>  { ... }
>
> Foo<throws MyException>  foo1 = ... //1
> Foo<MyException>  foo2 = ... //2
> foo1 = foo2; //3
>
> *) What is the type parameter of Foo in (1) ? A disjunctive type having
> one component (of type MyException)? Or a straight type-parameter (non
> disjunctive) of type MyException?
>
> *) is (2) allowed? If so what is the semantics? Does the singleton type
> MyException get converted into a disjunctive type having just one
> component (of type MyException)?
>
> *) is (3) allowed? If so, depending on the semantics you choose for (1)
> and (2), aren't we (indirectly perhaps) already supporting a form of
> 'covariance', as we assume that C<E>  <: C<throws E>  because E<: throws
> E ? If so, what are the consequences of these subtyping rule?
>
> Maurizio
>    

you can also add:

Foo<? extends throws MyException> foo3 = ...
and
Foo<throws ? extends MyException> foo4 = ...

And please remember that use-site variance (i.e ? extends/super) is 
something that is not easy to grasp,
only few of my students understand it correctly. Declaration site 
variance seems easier.

Rémi