Exception transparency

[Maurizio Cimadamore]

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

> Thanks
> Maurizio
>
>