Effective Java 第三版——69. 仅在发生异常的条件下使用异常

Tips
书中的源代码地址：https://github.com/jbloch/effective-java-3e-source-code
注意，书中的有些代码里方法是基于Java 9 API中的，所以JDK 最好下载 JDK 9以上的版本。

Effective Java, Third Edition

异常

当充分发挥异常的优势时，它可以提高程序的可读性、可靠性和可维护性。如果使用不当，则会产生相反的效果。本章提供了有效使用异常的指南。

69. 仅在发生异常的条件下使用异常

有一天，如果你运气不好，你可能会偶然发现这样一段代码:

// 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();

那么为什么有人会使用基于异常的循环而不是尝试和正确的用法？ 根据错误推理提高性能是一种错误的尝试，因为虚拟机检查所有数组访问的边界，由编译器隐藏但仍然存在于for-each循环中的正常循环终止测试是多余的，应该避免。 这个推理有三个问题：

• 因为异常是为特殊情况设计的，所以JVM实现者几乎没有试图让它们像显式测试一样快。
• 将代码放在try-catch块中会抑制虚拟机实现可能执行的某些优化。
• 遍历数组的标准习惯用法不一定会导致冗余检查。许多虚拟机实现对它们进行了优化。

事实上，基于异常的习惯用法比标准用法慢得多。在我的机器上，100个元素的数组，基于异常的习惯用法的速度大约是标准习惯用法的两倍。

基于异常的循环不仅混淆了代码的目的，降低了代码的性能，而且不能保证它能正常工作。如果循环中存在bug，使用异常进行流控制可以掩盖该bug，从而大大增加调试过程的复杂性。假设循环体中的计算调用一个方法，该方法对一些不相关的数组执行越界访问。如果使用合理的循环习惯用法，该bug将生成一个未捕获的异常，导致线程立即终止，并带有完整的堆栈跟踪。如果使用错误的基于异常的循环，则会捕获与bug相关的异常，并将其误解为正常的循环终止。

这个示例说明的道理很简单：顾名思义，异常仅用于特殊情况; 它们永远不应该用于正常的控制流程。 通常来说，使用标准的、易于识别的习惯用法，而不是声称可以提供更好性能的过度聪明的技术。即使性能优势是真实存在的，但在稳步改进平台实现的情况下，这种优势也可能不复存在。然而，来自过度聪明的技术的细微缺陷和维护难题肯定会继续存在。

这个原则对API设计也有影响。一个设计良好的API不能强迫它的客户端为正常的控制流使用异常。只有在某些不可预知的条件下才能调用具有“状态依赖(state-dependent)”方法的类，通常应该有一个单独的“状态测试(state-testing)”方法，指示是否适合调用状态依赖方法。例如，Iterator接口具有依赖于状态的next方法和对应的状态测试方法hasNext。这支持使用传统for循环(以及for-each循环，其中内部使用了hasNext方法)在集合上迭代的标准习惯用法：

for (Iterator i = collection.iterator(); i.hasNext(); ) {
    Foo foo = i.next();
    ...
}

如果Iterator缺少hasNext方法，则客户端将被迫执行此操作：

// Do not use this hideous code for iteration over a collection!
try {
    Iterator i = collection.iterator();
    while(true) {
        Foo foo = i.next();
        ...
    }
} catch (NoSuchElementException e) {
}

这数组迭代的例子非常类似于本条目一开始的那个例子。除了冗长和误导之外，基于异常的循环很可能执行得很差，并且可以掩盖系统中不相关部分中的bug。

提供单独的状态测试方法的另一种方式是，让依赖于状态的方法返回一个空的Optional值(条目 55)，或者在它不能执行所需的计算时返回一个区分值，比如null。

下面是一些指导原则，帮助你在状态测试方法，Optional的或区分的返回值之间进行选择。如果要在没有外部同步的情况下并发地访问对象，或者受制于外部引发的状态转换，则必须使用Optional的或可区分的返回值，因为在调用状态测试方法与其依赖于状态的方法之间的间隔内，对象的状态可能会发生变化。如果一个单独的状态测试方法将重复依赖于状态的方法的工作，那么性能问题可能要求使用一个Optional的或可区分的返回值。在所有其他条件相同的情况下，状态测试方法略优于区分的返回值。它提供了更好的可读性，而且不正确的使用可能更容易检测：如果忘记调用状态测试方法，依赖于状态的方法将抛出异常，使错误变得明显；如果忘记检查一个可区分的返回值，那么这个bug可能很微妙。这不是Optional返回值的问题。

总之，异常是针对特殊情况而设计的。不要将它们用于正常的控制流程，也不要编写强制其他人这样做的API。