Trying to agree semantics for closures in Java isn't easy. Maybe we should look at what some other Java-like languages have done - Nice, Groovy and Scala.
The first thing to notice is that they all have closures. Java really is the odd one out now. The devil is in the detail though. Specifically, what do these languages do with the interaction between continue/break/return and the closure?
Nice
// syntax for the higher order function
String find(String -> boolean predicate) {
...
boolean result = predicate(str);
...
}
// syntax 1 to call the higher order function
String result = strings.find(String str => str.length() == 2);
// syntax 2 to call the higher order function
String result = strings.find(String str => {
// other code
return str.length() == 2;
});
Nice has two variants of calling the closure. Syntax 1, where there is just a single expression has no braces and no return keyword. Syntax 2, has a block of code in braces, and uses the return keyword to return a value back to the higher order function.
There is a control abstraction syntax variant, where again the return keyword returns back to the higher order function. Similarly, the continue and break keywords may not cross the boundary between the closure and the main application.
Groovy
// syntax for the higher order function
def String find(Closure predicate) {
...
boolean result = predicate(str)
...
}
// syntax 1 to call the higher order function
String result = strings.find({String str -> str.length() == 2})
// syntax 2 to call the higher order function
String result = strings.find({String str ->
// other code
return str.length() == 2;
})
Groovy has many possible variants of calling the closure (with optional types). Semicolons at the end of lines are always optional, as is specifying the return keyword. So syntax 1 and 2 are naturally the same in Groovy anyway. However, the example does show that if you do use the return keyword, then it returns from the closure to the higher order function.
There is a control abstraction syntax variant, where again the return keyword returns back to the higher order function. Similarly, the continue and break keywords may not cross the boundary between the closure and the main application.
Scala
// syntax for the higher order function
def find(predicate : (String) => boolean) : String = {
...
boolean result = predicate(str)
...
}
// syntax 1 to call the higher order function
String result = strings.find({String str => str.length() == 2});
// syntax 2 to call the higher order function
String result = strings.find({String str =>
// other code
str.length() == 2;
});
In Scala, like Groovy, semicolons at the end of lines are always optional. However, the key difference with Groovy is that the return keyword is always linked to the nearest enclosing method, not the closure. If that method is no longer running when the closure is invoked, then a NonLocalReturnException may be thrown.
There is a control abstraction syntax variant, where again the return keyword will return from the enclosing method. Scala does not support the continue and break keywords.
BGGA and FCM
Hopefully, the above is clear enough to show that Nice and Groovy operate in a similar manner (return always returns to the higher order function), whereas Scala is different (return will always return the enclosing method, but you may get an exception). This is especially noticeable when Nice/Groovy is used in a control abstraction syntax manner, because then the return keyword looks odd as it returns from an 'invisible' closure (the code often just looks like a keyword).
So how do the Java proposals compare?
BGGA follows the Scala model. If you write a return within the closure block it will return from the enclosing method. And you might get a NonLocalReturnException if that enclosing method has completed processing. BGGA also handles continue and break similarly.
FCM follows the Nice/Groovy model. If you write a return within the closure block it will return to the higher order function method, and there are no possible exceptions. There is no way to return from the enclosing method. Similarly, FCM prevents continue and break from escaping the boundary of the closure block.
Which model is right? Well, both have points in their favour and points against.
Scala/BGGA is more powerful as it allows return from the enclosing method, but it comes with the price of a weird exception - NonLocalReturnException. FCM, is thus slightly less powerful, but has no risk of undesirable exceptions.
Personally I can see why Scala's choice makes sense in Scala - because the language generally omits semicolons and return statements. But I'm not expecting us to remove semicolons from Java any time soon, or make return optional on all methods, so Scala's choices within a Java context seem dubious.
Feedback
Feedback welcomed of course, including examples from other languages (C#, Smalltalk, Ruby, ...).
And what about adding a new keyword to FCM to allow returning from the enclosing method? Such as "break return"? It would expose FCM to NonLocalReturnException though...
