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

david.moss at david.moss at
Wed Mar 2 09:21:59 PST 2011


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

interface I { int method(); }

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

Kind Regards,


-----Original Message-----
From: lambda-dev-bounces at
[mailto:lambda-dev-bounces at] 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

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

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


On Tue, Mar 1, 2011 at 5:35 PM, Neal Gafter <neal at> 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 
(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.

More information about the lambda-dev mailing list