ITEM 69: USE EXCEPTIONS ONLY FOR EXCEPTIONAL CONDITIONS
有时，我们很不幸的会遇上这样的代码：
// Horrible abuse of exceptions. Don't ever do this!
try {
int i = 0;
while(true) range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}
这段代码是做什么的？从表面看，它的语义一点也不明显，这就是不使用它的充分理由(第67项)。事实证明，这是一个非常糟糕的习惯用法，用于遍历数组中的元素。当无限循环试图访问数组边界之外的第一个数组元素时，通过抛出、捕获和忽略ArrayIndexOutOfBoundsException 来终止无限循环。它应该等同于循环遍历数组的标准习惯用法，这对于任何Java程序员来说都是一目了然的:
for (Mountain m : range)
m.climb();
那么，为什么会有人使用基于异常的循环，而不使用边界测试呢？由于JVM检查所有数组访问的界限，所以编译器隐藏但仍然存在于 for-each 循环中的常规循环终止测试是冗余的，应该避免，因此基于错误的推理来提高性能是一种错误的尝试。这种推论有三方面是错误的:
- 因为异常是为特殊情况设计的，所以JVM实现者几乎没有动力让它们与显式测试一样快。
- 将代码放在 try-catch 块中会抑制 JVM 实现可能执行的某些优化。
- 遍历数组的标准习惯用法不一定会导致冗余检查。许多JVM实现都将它们优化掉了。
事实上，基于异常的习惯用法比标准用法慢得多。在我的机器上，基于异常的用法的速度大约是包含100个元素的数组的标准习惯用法的两倍。
基于异常的循环不仅混淆了代码的用途并降低了它的性能，而且不能保证它能正常工作。如果循环中存在错误，则使用流控制的异常可以掩盖错误，从而极大地复杂化调试过程。假设循环体中的计算调用了一个方法，该方法对一些不相关的数组执行越界访问。如果使用了合理的循环习惯用法，则该bug将生成未捕获的异常，从而导致线程立即终止，并执行完整的堆栈跟踪。如果错误的使用了基于异常的循环，则与bug相关的异常将被捕获并被误解为正常的循环终止。
这一节的内容很简单：如其名字所暗示的，异常只用于特殊情况；它们不应该用于普通的控制流。更一般地说，使用标准的、易于识别的习惯用法，而不是那些声称可以提供更好性能的过于聪明的技术。即使性能优势是真实存在的，但在平台实现稳步改进的情况下，这种优势也可能不复存在。然而，来自过于聪明的技术的细微错误和维护问题肯定会继续存在。
这个原则也适用于API设计。一个设计良好的API不能强迫它的客户端为普通的控制流使用异常。具有“状态相关”方法的类(只能在某些不可预知的条件下调用)通常应该具有一个单独的“状态测试”方法，该方法指示是否适合调用状态相关的方法。例如，迭代器接口有状态相关的next方法和对应的状态测试方法hasNext。这使得使用传统的for循环(以及for-each循环，其中hasNext方法在内部使用)在集合上迭代成为可能:
for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
Foo foo = i.next();
...
}
如果Iterator缺少hasNext方法，客户将被迫这样做:
// Do not use this hideous code for iteration over a collection!
try {
Iterator<Foo> i = collection.iterator();
while(true) {
Foo foo = i.next();
...
}
} catch (NoSuchElementException e) { }
在开始这个项目的数组迭代示例之后，这看起来应该非常熟悉。除了冗长和误导之外，基于异常的循环很可能执行得很差，并且可以掩盖系统中不相关部分的bug。
提供单独的状态测试方法的另一种方法是让依赖于状态的方法返回一个空的可选值(item 55)，或者在它不能执行所需的计算时返回一个特殊的值，比如null。
下面是一些指导原则，帮助您在状态测试方法和Optional 或区分的返回值之间进行选择。
如果一个对象是被并发地访问没有外部同步或受到外部诱导状态转换，您必须使用一个 Optional 或区分的返回值，因为在调用状态测试方法和其依赖于状态的方法之间的间隔中，对象的状态可能发生变化。如果一个状态测试方法将重复被状态相关的方法的调用，则出于性能考虑，可以使用一个 Optional 或可区分的返回值。在所有其他条件相同的情况下，状态测试方法略优于区分的返回值。它提供了更好的可读性，并且更容易检测到不正确的使用：如果您忘记调用状态测试方法，依赖状态的方法将抛出一个异常，使错误变得明显；如果您忘记检查一个可分辨的返回值，那么这个错误可能很微妙。这不是 Optional 返回值的问题。
总之，异常是为特殊情况设计的。不要将它们用于普通的控制流，也不要编写强迫别人这么做的api。
网友评论