java - Why must throw statements be enclosed with a full code block in a lambda body?

Question

If there is a single statement in a lambda function, we can omit defining the full code block for it:

new Thread(() -> System.out.println());

Why is that not the case for statements that throw exceptions? This yields a compilation error stating '{' expected:

new Thread(() -> throw new RuntimeException());

Of course, enclosing the lambda body in a code block works:

new Thread(() -> {
    throw new RuntimeException();
});

question from:https://stackoverflow.com/questions/43307989/why-must-throw-statements-be-enclosed-with-a-full-code-block-in-a-lambda-body

Answer 1

A throw statement is, well, a statement and not an expression so it must be placed within braces. According to this article, the Java Expert Group had an informal survey on the syntax of lambdas at the time, and there were four options:

• Strawman: #(arglist)(expr) and #(arglist){statements}
• BGGA: { args -> statements } (similar to Scala and Groovy)
• SotL: #{ args -> statements}
• Redmond: (args) -> { statements }

Ultimately, the choice was to adopt a syntax similar to that of C# according to this thread, which also looks closest to the last option above as far as I can see. In C#, there is a distinction between expression lambdas and statement lambdas:

Expression lambda (C#):

(input parameters) => expression

Statement lambda (C#):

(input parameters) => {statement;}  

The syntax is explained in this MSDN documentation page.

And the rationale for choosing this syntax over the other options is mentioned in the previous thread:

The decision to choose this syntax was twofold:

• The syntax scores "pretty well" on most subjective measures (though has cases where it looks bad, just like all the others do). In particular, it does well with "small" lambdas that are used as method arguments (a common case), and also does well with large (multi-statement) lambdas.

• Despite extensive searching, there was no clear winner among the alternatives (each form had some good aspects and some really not very good aspects, and there was no form that was clearly better than the others). So, we felt that it was better to choose something that has already been shown to work well in the two languages that are most like Java -- C# and Scala -- rather than to invent something new.