Push 23 August 1bb5b46bb326 fixes one bug, but introduces another

[Maurizio Cimadamore]

Hi Peter
> Do you have to infer the thrown types of the lambda body even before the lambda body is "resolved" ? Can't this be done afterwards?
>    
Doing it 'before' resolution has the advantage of narrowing down the set 
of potential applicable methods - which means less ambiguity errors and 
less need for explicit types at the call site.
> Maybe it's because you are considering lambda's thrown types in the resolution of the code surrounding the lambda expression (for example in the resolution of the invocation of the overloaded method where the lambda expression is one of it's parameters).
>
> For example this program:
>
>
> public class Closures
> {
>    public interface IoSam { void run(String s) throws java.io.IOException; }
>
>    public interface TxtSam { void run(String s) throws java.text.ParseException; }
>
>    public static void doIt(IoSam ioSam) throws java.io.IOException
>    {
>      ioSam.run("IoSam");
>    }
>
>    public static void doIt(TxtSam txtSam) throws java.text.ParseException
>    {
>      txtSam.run("TxtSam");
>    }
>
>    public static void main(String[] args) throws Exception
>    {
>      try
>      {
>        doIt(#(String s){ System.out.println("Ivoked via " + s); throw new java.io.IOException(); });
>      }
>      catch (java.io.IOException e) {}
>
>      try
>      {
>        doIt(#(String s){ System.out.println("Ivoked via " + s); throw new java.text.ParseException(null, 0); });
>      }
>      catch (java.text.ParseException e) {}
>    }
> }
>
>
> prints:
>
>
> Ivoked via IoSam
> Ivoked via TxtSam
>
>
> Which shows that the resolution of overloaded method is taking the throws types of lambda expression into the consideration.
>
> I don't think this is something that is desirable. Lambda return type and parameter types yes, but not throws types. They should just be checked and always inferred in direction "lambda expression" ->  SAM method throws type parameter...
>    
Which means in the above case you have no other option than issuing an 
ambiguity error, since both methods are applicable (unless you look at 
thrown types).

Maurizio