Question on exception transparency

[Maurizio Cimadamore]

Hi Peter,
now that I look at your example more carefully (I was doing a bloody 
merge with b105 :-) ) I confirm that, at least in principle, the 
following should compile and infer 'void' instead of Exception:

       forEach(
          Arrays.asList("a", "b", "c"),
          #(String s){ System.out.println("element: " + s); }
       );

I will fix this soon.

Maurizio


On 12/08/10 17:25, Peter Levart wrote:
> On 08/12/10, Maurizio Cimadamore wrote:
>    
>> On 12/08/10 13:40, Peter Levart wrote:
>>      
>>> import java.util.*;
>>>
>>> public class Closures
>>> {
>>>     public interface Block<T, throws E>   { void run(T param) throws E; }
>>>
>>>     public static<T, throws E>
>>>       void forEach(Iterable<T>   iterable, Block<? super T, E>   block) throws E
>>>     {
>>>       for (T obj : iterable) block.run(obj);
>>>     }
>>>
>>>     public static void main(String[] args)
>>>     {
>>>       // example 1:
>>>       forEach(
>>>         Arrays.asList("a", "b", "c"),
>>>         #(String s){ System.out.println("element: " + s); }
>>>       );
>>>
>>> // example 2 - javac throws NPE:
>>> //    Closures.<String, void>forEach(
>>> //      Arrays.<String>asList("a", "b", "c"),
>>> //      Block<String, void>   #(String s){ System.out.println("element: " + s); }
>>> //    );
>>>     }
>>> }
>>>
>>>        
>> The following works for me:
>>
>> Closures.forEach(
>>         Arrays.<String>asList("a", "b", "c"),
>>         Block<String, void>  #(s){ System.out.println("element: " + s); }
>>       );
>>
>> I guess  the NPE has been fixed in the last push.
>>
>>      
> Yes, that works now. But the following:
>
>        forEach(
>           Arrays.asList("a", "b", "c"),
>           #(String s){ System.out.println("element: " + s); }
>        );
>
> ... is currently no better than:
>
>        forEach(
>           Arrays.asList("a", "b", "c"),
>           #(s){ System.out.println("element: " + s); }
>        );
>
>
> They both infer "Exception" as the thrown type. Can this be improved? Is specifying lambda expression's parameter type actualy doing any help here?
>
> My naive uninformed understanding is that If the algorithm for method resolution worked in 2 passes:
>
> 1st pass would resolve method without taking into account throws type parameters
> 2nd pass would "check and apply" throws type parameters for the resolved method
>
> ...then even in the presence of overloaded methods exception transparency could work without explicitly specifying type parameters either on method or prefixing lambda with target SAM type.
>
> Peter
>