浅谈Java 7的闭包与Lambda表达式之优劣

核心提示： 当我们写一个方法A去调用方法B时，我们要么在方法A中使用try...catch捕获B抛出的方法，浅谈Java 7的闭包与Lambda表达式之优劣(5)，要么在方法A的签名中标记“会抛出同样的异常”，如上面的myMethodCaller方法，保存着文件名，要求获得它的标准路

当我们写一个方法A去调用方法B时，我们要么在方法A中使用try...catch捕获B抛出的方法，要么在方法A的签名中标记“会抛出同样的异常”。如上面的myMethodCaller方法，便在内部处理了BException异常，而只会对外抛出AException。Java便使用这种方法严格限制了类库的异常信息。

Checked Exception是一个有争议的特性。它对于编写出高质量的代码非常重要，因为在哪些情况抛出异常其实都是方法契约的一部分（不仅仅是签名或返回值的问题），应该严格遵守，在类库升级时也不能破坏，否则便会产生兼容性的问题。例如，您关注MSDN里的文档时，就会看到异常的描述信息，只不过这是靠“文档”记录的，而Java则是强制在代码中的；但是，从另一个角度说，Checked Exception让代码编写变得非常麻烦，这导致的一个情况便是许多人在写代码时，自定义的异常全都是RuntimeException（因为不需要标记），每个方法也都是throws Exception的（这样代码中就不需要try...catch了），此时Checked Exception特性也基本形同虚设，除了造成麻烦以外几乎没有带来任何好处。

我之前常说：一个特性如果要被人广泛接受，那它一定要足够好用。现在如Scala和Grovvy等为Java设计的语言中都放弃了Checked Exception，这也算是从侧面印证了Checked Exception的尴尬境地吧。

而Checked Exception对于如今Lambda或闭包来说，在我看来更像是一种硬伤。为什么这么说？举个例子吧，假如有这么一个map方法，可以把一个数组映射成另一个类型数组：

public　R[]　map(T[]　array,　Func<T,　R>　mapper)　{　...　}

好，那么比如这样一个需求：给定一个字符串数组，保存着文件名，要求获得它的标准路径。从表面上看来，我们可以这样写：