The lambda conversion and a lambda body that doesn't complete.

[david.moss at ubs.com]

Well,

At the very least it should be allowed because the following already is:

interface I { int method(); }

class C implements I {
	@Override
	public int method() {
		throw new RuntimeException("whatever");
	}
} 


Kind Regards,

David.

-----Original Message-----
From: lambda-dev-bounces at openjdk.java.net
[mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Ben Evans
Sent: 02 March 2011 18:10
To: Neal Gafter; lambda-dev
Subject: Re: The lambda conversion and a lambda body that doesn't
complete.

OK, I'll bite.

What's the interest in this use case?

As I read it, you're saying that if the compiler can provably guarantee
that a lambda cannot return normally, then the compiler should ignore
the return type when SAM-converting. Is that the property we're after?

What's the use case for this feature? How often are we actually going to
write code inside a lambda which the compiler can guarantee will not
return normally? Should we even be encouraging people to write code like
that?

Glaringly obvious use cases and other smackdown in 3-2-1.... :)

Ben

On Tue, Mar 1, 2011 at 5:35 PM, Neal Gafter <neal at gafter.com> wrote:

> Dear Lambdans-
>
> Given
>
> *interface F {
>    int invoke();
> }*
>
> I would like to be able to write
>
> *F x = #{ throw new Exception(); };
> *
>
> (Modulo syntax - whatever the current syntax is)
>
> But according to the current draft specification that's not allowed 
> (the lambda as written can only be converted to a SAM with a void
return type).
>
> I think that whether or not the lambda's body can complete normally 
> should be taken into account in the lambda conversion to make this 
> legal.  As a point of information, the behavior I prefer is the 
> behavior of Scala, BGGA, and C# (among others).  This is also 
> consistent with the way method implementations work:
>
> *int f() { throw new Exception(); }*
>
> In the unfortunate case that you need use cases for this, draft 
> specification language, or suggestions for a straightforward 
> implementation, I can provide those.
>
> Cheers,
> Neal
>
>

Based on the present E-Mail exchange, and/or on the agreement reached
with you, respectively, UBS is entitled to contact you via insecure 
E-Mail:
(a) E-Mails contain substantial risks such as lack of confidentiality,
manipulation of content and sender, misdirection, viruses etc. UBS 
does not accept any liability for damages arising from use of
E-mail. Accordingly, UBS recommends to abstain from sending any
sensitive information via E-Mail, from forwarding the text received 
when submitting reply E-Mails and recommends to manually capture the 
E-Mail address in every instance. If you should wish to verify the 
content of this message, please request a hard-copy version.
(b) In principle, UBS does not accept any (purchase) orders, 
cancellation of orders or authorizations etc. via E-mail. If UBS 
receives such E-Mails, UBS is not obliged to expressly decline them.
If you have received this E-Mail by mistake or do not wish to be 
contacted by E-Mail in the future, you are kindly asked to inform UBS
accordingly. Any E-Mail received by mistake (including all its annexes)
needs to be destroyed and the content may not be forwarded nor disclosed
to any further persons.
c) This message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.
 
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.