Effective Java (异常处理).pdf

只针对异常情况才使用异常： 不知道你否则遇见过下面的代码： 代码如下: 复制代码 try { int i 0;3 while (true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) { } 这段代码的意图不是很明显，其本意就是遍历变量数组range 中的每一个元素，并执行元素的climb方法， 当下标超出range的数组长度时，将会直接抛出ArrayIndexOutOfBoundsException异常，catch代码块将会捕 获到该异常，但是未作任何处理，只是将该错误视为正常工作流程的一部分来看待。这样的写法确实给人 一种匪夷所思的感觉，让我们再来看一下修改后的写法： 代码如下: 复制代码 for (Mountain m : range) { m.climb(); } 和之前的写法相比其可读性不言而喻。那么为什么又有人会用第一种写法呢？显然他们是被误导了，他 们企图避免for-each循环中JVM对每次数组访问都要进行的越界检查。这无疑是多余的，甚至适得其反，因 为将代码放在try-catch块中反而阻止了JVM的某些特定优化，至于数组的边界检查，现在很多JVM实现都会 将他们优化掉了。在实际的测试中，我们会发现采用异常的方式其运行效率要比正常的方式慢很多。 除了刚刚提到的效率和代码可读性问题，第一种写法还会掩盖一些潜在的Bug，假设数组元素的climb方 法中也会访问某一数组，并且在访问的过程中出现了数组越界的问题，基于该错误，JVM将会抛出 ArrayIndexOutOfBoundsException异常，不幸的是，该异常将会被climb函数之外catch语句捕获，在未做任 何处理之后，就按照正常流程继续执行了，这样Bug也就此被隐藏起来。 这个例子的教训很简单：异常应该只用于异常的情况下，它们永远不应该用于正常的控制流。虽然有 的时候有人会说这种怪异的写法可以带来性能上的提升，即便如此，随着平台实现的不断改进，这种异常 模式的性能优势也不可能一直保持。然而，这种过度聪明的模式带来的微妙的Bug，以及维护的痛苦却依然 存在。 根据这条原则，我们在设计API的时候也是会有所启发的。设计良好的API不应该**它的客户端为了正 常的控制流而使用异常。如Iterator，JDK在设计时充分考虑到这一点，客户端在执行next方法之前，需要 先调用hasNext方法已确认是否还有可读的集合元素，见如下代码： 代码如下: 复制代码 for (Iterator i collection.iterator(); i.hasNext(); ) { Foo f i.next(); } 如果Iterator缺少hasNext方法，客户端则将**改为下面的写法： 代码如下: 复制代码 try { Iterator i collection.iterator(); while (true) Foo f i.next(); } catch (NoSuchElementException e) { } 这应该非常类似于本条目开始时给出的遍历数组的例子。在实际的设计中，还有另外一种方式，即验证可 识别的错误返回值，然而该方式并不适合于此例，因为对于next，返回null可能是合法的。那么这两种设计 方式在实际应用中有哪些区别呢？ 1. 如果是缺少同步的并发访问，或者可被外界改变状态，使用可识别返回值的方法是非常必要的，因 为在测试状态(hasNext)和对应的调用(next)之间存在一个