所有新特性中争议最大的，当然就是此条：return/break/continue to behave inside closures like these statements work in other blocks (such as the block on a for() or while() loop.
简而言之，这就是统一block和closure。
这里我忍不住王婆卖瓜一下，其实我已经直觉出这个味道。我在1月16日在groovy-dev上re了Mike Spille一篇：
I think we should regard
foo() {}as syntax-sugar, this feature eliminate the difference between built-in flow structure and user-defined method call.If = { condition, doSth | if (condition) doSth() } t = { println 'Hello!' } if (true) { println 'Hello!' } // built-in if If (true) { println 'Hello!' } // user-defined If is similar to built-in if, that's groovy! If(true, t) // normal method call If(true, { println 'Hello!' }) // normal method call even the last param is a anonymous closure > > The puzzling errors bit is also why I favor a keyword for closures. It'll > not only greatly simplify the grammar and parser, but I think it's better > for users too. It clearly signals where closures are in your code, and > avoids the problems of _users_ not knowing when they have a closure and > when they have a block.I think there is no essential difference between closure and block. User have a block, then want to reuse the block. make the block can be passed or returned or parameterized --- that is closure.
现在看来，当时我已经接近摆脱最初仅仅视closure为JavaScript中anonymous function等价物的想法了。我已经直觉到此closure与一般block之间的微妙关系。
closure的syntax很大程度上消除了内建流程结构和用户定义方法的区别。换言之，我们可以很方便的写出接受closure参数的方法，使得其调用语法能非常类似while, when（不带else的if）的语法结构！虽然还是无法复制for(;;)和if-else这样特殊的语法构造，但这已经是很大的震撼。
进而，我发现，就应用程序员角度而言，block和closure并不存在本质区别。block可以看作一个代码段，而closure是可以重用（可传递、返回以及参数化）的代码段。
然而closure和传统flow控制具有一定的冲突，这主要表现在如何实现break、continue语义。之前的建议一般是要求closure返回一个特定常量标记如Closure.BREAK来指示，然后由closure的调用者负有责任来处理此标志。
更大的问题在于，同样作为代码功能抽象和复用的单位，closure与function(method)发生了冲突。这就是要命的return问题！
显然，按照一般思路，closure在底层就是一个function或者说method，匿名closure形同block的 { param | expression } 的简洁构造可被视作一种语法sugar。并且从最初一直到现在，此sugar主要是为了达到精巧的GPath的简洁性。且另一方面，在从js或者是对泛函式编程（fp）有点入门知识的人看来，closure都应该与function划上等号。
应该说，groovy的closure一开始也是如此。唯一是，同样为了GPath的简洁性，采用了可省略return的设计（直接返回最后一个语句的值）。
从此，groovy的codebase中，所有closure几乎都没有return关键字的出现。因为几乎没有必要，所以似乎没有理由记得它甚至提到它。由此，一扇门打开了……
考虑一个传统程序。这个函数检查名为file的文件的每一行，并返回满足filter的第一行行号，否则返回-1。
def findLine(file, filter) {
lineNo = 0
f = new File(file)
while(!f.isEOF()) {
line = f.readLine()
if (filter(line)) return lineNo;
else lineNo
}
return -1
}
现在一个newbie刚刚看了几个closure的例子，兴奋异常，于是换用closure style来撰写：
def findLine(file, filter) {
lineNo = 0
new File(file).eachLine { line |
if (filter(line)) return lineNo; else lineNo
}
return -1
}
Ok，一切看上去没错，代码更清晰的表达了程序的主旨，几乎没有多余的东西。
但是，不幸的是，这段程序在Classic Groovy里面是无法达到预期效果的，findLine总是返回-1！
因为在eachLine之后的匿名closure中的return是从该closure返回到eachLine方法内部的调用点上（事实上eachLine方法只是简单的忽略这个返回值，没有任何人期待它的到来），而不是如程序员所期望的返回给findLine的调用者！
ok，这是程序员的问题，误用了return——有人会简单的下结论。如何用建议的Closure.BREAK常量标志来达成这个功能先不论，仅仅考虑到这个return是多么直觉的事情，并且groovy的目标就是要让程序员能按直觉办事（去掉烦心的程序终结符;居然还允许跨行，就是例证），就不能简单的把问题归咎于程序员。
照例说，在这个结构里面，return的用意非常清楚，不带偏见的说，任何一个Java程序员转向groovy之后几乎都会写出这样的程序。由于 closure大量被用于简化迭代结构（Martin Flower号称他因此在没有closure的语言中是如此怀念closure），对于从c-style转过来的程序员来说，面对最常使用的each，自然把它看作for, while结构的替代物，所以把return视作从findLine返回，而不是从匿名closure返回是狠自然的。
对此问题，Mike Spille的意见是：一切起因于closure实在太像block，程序员忘记了此处实际上是个语法sugar，本质是个method而并不是一个 block，因而诱导了程序员错误的期望该return的返回位置。既然如此，我们就应该明确哪里是block哪里是closure。其建议就是增加一个指示closure的关键字，譬如def { closure code... }
对此，有人尖锐的指出，那还不如去用C#的delegate！（另一方面，那也是js的实际情况，function关键字就相当于此关键字）
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
