有一天，如果你运气不好，你可能会偶然发现这样一段代码:
image.png
这段代码是做什么的?从检查结果看，它一点也不明显，这就是不使用它的充分理由( item67 )。事实证明，这是一个非常糟糕的习惯用法，用于遍历数组的元素。当试图访问数组边界之外的第一个数组元素时，无限循环通过抛出、捕获和忽略ArrayIndexOutOfBoundsException来终止。它应该等同于循环遍历数组的标准习惯用法，任何Java程序员都可以立即识别:
image.png
那么，为什么会有人使用基于异常的循环而不使用try和true呢?这是一个错误的尝试，以提高性能的基础上的错误原因，由于VM检查所有数组访问的边界，编译器隐藏但仍然存在于for-each循环中的常规循环终止测试是冗余的，应该避免。这种推理有三件事是错误的:
- 因为异常是为特殊情况设计的，所以JVM实现者几乎没有动力让它们像显式测试一样快。
- 将代码放在try-catch块中会抑制JVM实现可能执行的某些优化。
- 遍历数组的标准习惯用法不一定会导致冗余检查。许多JVM实现对它们进行了优化。
事实上，基于异常的习惯用法比标准用法慢得多。在我的机器上，基于异常的习惯用法的速度大约是100个元素数组的标准习惯用法的两倍。
基于异常的循环不仅混淆了代码的目的，降低了代码的性能，而且不能保证它能正常工作。如果循环中存在bug，使用异常进行流控制可以掩盖该bug，从而大大增加调试过程的复杂性。假设循环体中的计算调用一个方法，该方法对一些不相关的数组执行越界访问。如果使用合理的循环习惯用法，该bug将生成一个未捕获的异常，导致线程立即终止，并带有完整的堆栈跟踪。如果使用错误的基于异常的循环，则会捕获与bug相关的异常，并将其误解为正常的循环终止。
这个故事的寓意很简单:例外情况，正如其名称所暗示的，只适用于例外情况;它们不应该用于普通的控制流。更一般地说，使用标准的、易于识别的习惯用法，而不是声称可以提供更好性能的过于聪明的技术。即使性能优势是真实存在的，但在稳步改进平台实现的情况下，这种优势也可能不复存在。然而，来自过于聪明的技术的细微缺陷和维护难题肯定会继续存在。
这个原则对API设计也有影响。一个设计良好的API不能强迫它的客户端为普通的控制流使用异常。只有在某些不可预知的条件下才能调用具有“状态依赖”方法的类，通常应该有一个单独的“状态测试”方法，指示是否适合调用状态依赖方法。例如，Iterator接口具有依赖于状态的方法next以及对应的状态测试方法hasNext。这支持使用传统for循环(以及for-each循环，其中内部使用了hasNext方法)在集合上迭代的标准习惯用法:
image.png
如果Iterator缺少hasNext方法，客户端将被迫这样做:
image.png
在开始该项目的数组迭代示例之后，这看起来应该非常熟悉。除了冗长和误导之外，基于异常的循环很可能执行得很差，并且可以掩盖系统中不相关部分中的bug。
提供单独的状态测试方法的另一种方法是让依赖于状态的方法返回一个空的Optional(item55)，或者在它不能执行所需的计算时返回一个区分值，比如null。
下面是一些指导原则，帮助您在状态测试方法和可选的或区分的返回值之间进行选择。如果一个对象是被并发地访问没有外部同步或受到外部诱导状态转换,您必须使用一个optional或有区别的返回值,随着对象的状态之间的时间间隔可以改变依赖政府声明测试方法及其方法的调用。如果一个单独的状态测试方法将重复依赖于状态的方法的工作，那么性能问题可能要求使用一个optional或有区别的返回值。在所有其他条件相同的情况下，状态测试方法略优于有区别的返回值。它提供了更好的可读性，不正确的使用可能更容易检测:如果忘记调用状态测试方法，依赖于状态的方法将抛出异常，从而使错误变得明显;如果您忘记检查一个可区分的返回值，那么这个bug可能很微妙。这不是可选返回值的问题。
总之，异常是为异常条件设计的。不要将它们用于普通的控制流，也不要编写迫使其他人这样做的api。
本文写于2019.7.22，历时1天
网友评论