return-from-lambda viewed as dangerous, good alternatives

[David.Moss at ubs.com]

+1 (at least).

If "transparent" returns are really necessary, I would recommend a
different syntax. Something along the lines of:

Class Foo {
    public int bar() {
        #int() {
            if (someCondition()) {
                return 42;
                // return from the lambda expression
            } else if (anotherCondition()) {
                return from bar 56;
                // terminate the named method call
            } else {
                return from caller 99;
                // where 'caller' is a keyword, similar to 'this',
                // which points the outmost method call (instead
                // of the current object). In this case 'bar()',
                // but which can be used when the method's name
                // is not known by the programmer (eg. a listener).
            }
        }
    }
}

> I think most Java programmers will think of closures as a
> more terse version of anonymous inner classes (like CICE).
> They will consider these two bits of code equivalent:
> 
>     Thread thread = new Thread(new Runnable() {
>         public void run() {
>             if (shouldDie()) {
>                 return;
>             }
>             ...;
>         }
>     });
> 
> and:
> 
>     Thread thread = new Thread(#() {
>         if (shouldDie()) {
>             return;
>         }
>         ...;
>     });



Kind Regards,

David.

--

"Where's the Kaboom? There was supposed to be an Earth-shattering
Kaboom!" - Marvin the Martian

"Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it." - Alan Kay
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.