- 第57条、只针对异常的情况才使用异常
- 第58条、对可恢复的异常使用检测性异常，对编程错误使用运行时异常
- 第59条、避免不必要地使用检测性异常
- 第60条、优先使用标准的异常
- 第61条、抛出与抽象相对应的异常
- 第62条、每个方法抛出的异常都要有文档
- 第63条、在细节消息中包含能捕获失败的信息
- 第64条、努力使失败保持原子性
- 第65条、不要忽略异常
第57条、只针对异常的情况才使用异常
不知道你否则遇见过下面的代码。1
2
3
4
5
6try {
int i = 0;3
while (true)
range[i++].climb();
}catch (ArrayIndexOutOfBoundsException e) {
}
这段代码的意图不是很明显，其本意就是遍历变量range[]中的每一个元素，并执行元素的climb()，当下标超出range[]的长度时，将会直接抛出ArrayIndexOutOfBoundsException异常，catch代码块将会捕获到该异常，但是未作任何处理，只是将该错误视为正常工作流程的一部分来看待。这样的写法确实给人一种匪夷所思的感觉，让我们再来看一下修改后的写法。1
2
3for (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()已确认是否还有可读的集合元素，见如下代码。1
2
3for (Iterator i = collection.iterator(); i.hasNext(); ) {
Foo f = i.next();
}
如果Iterator缺少hasNext()，改为下面的写法。1
2
3
4
5
6try {
Iterator i = collection.iterator();
while (true)
Foo f = i.next();
}catch (NoSuchElementException e) {
}
这应该非常类似于本条目开始时给出的遍历数组的例子。在实际的设计中，还有另外一种方式，即验证可识别的错误返回值，然而该方式并不适合于此例，因为对于next()，返回null可能是合法的。那么这两种设计方式在实际应用中有哪些区别呢？