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

[Peter Levart]

On 08/27/10, Maurizio Cimadamore wrote:
> 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).

Yes, and that is, in my opinion, a better choice. Designing an API with overloaded methods on the grounds of throws types of lambda expressions passed to those methods, is very prone to errors. Changing the body of the lambda expression slightly can have adverse effects on the resolution of overloaded method. The same is true when the return type of lambda expression changes, but that is much less likely to happen - if lambda was written to return a String, one will very rarely change it into something that returns say a Number. On the other hand, inferred throws types from lambda body can change very rapidly when you add or remove methods to/from the lambda body.

> 
> Maurizio
> 

Peter