充分发挥异常的优点,可以提高程序的可读性、可靠性和可维护性。如果使用不当,它们也会带来负面影响。
某一天,如果你不走运的话,可能会碰到下面这样的代码:
try {
int i = 0;
while(true){
range[i++].climb();
}
} catch (ArrayIndexOutOfBoundsException e) {
}
这段代码有什么作用?看起来根本不明显他没有真正被使用的原因是没有更好的进行优化。事实证明,作为一个要对数组元素进行遍历的实现方式,他的构思是非常拙劣的。当这个循环企图访问数组边界之外的第一个数组元素时,用抛出,捕获、忽略ArrayIndexOutOfBoundsException的手段来达到终止无限循环的目的。假定他与数组循环的标准模式是等价的,对于任何一个Java程序员来说,下面的标准模式一看就会明白:
for(Mountain m : range){
m.climb();
}
那么,为什么有人会优先使用基于异常的模式,而不是用行之有效的模式呢?这是被误导了,他们企图利用Java的错误判断机制来提高性能,因为VM对每次数组访问都要检查越界情况,所以他们认为正常的循环终止测试被编译器隐藏了,但是在for-each循环中仍然可见,这无疑是多余的,应该避免。这种想法有三个错误:
一,因为异常机制的设计初衷使用于不正常的情形,所以很少会有JVM实现试图对它们进行优化,使得与显式的测试一样快速。
二,把代码放在try-cathch块中反而阻止了现代JVM实现本来可能要执行的某些特定优化。
三,对数组进行遍历的标准模式并不会导致冗余的检查,有些现代的JVM实现会将它们优化掉。
实际上,在现代的JVM实现上,基于异常的模式比标准模式要慢得多。
基于异常的循环不仅模糊了代码的意图,降低了他的性能,而且他还不能保证正常的工作,如果出现了不相关的bug,这个模式会悄悄的失效,从掩盖了这个bug,极大的增加了调试过程的复杂性。假设循环体中的计算过程调用了一个方法,这个方法执行了对某个不相关数组的越界访问。如果使用合理的模式,这个bug会产生未被捕捉的异常,从而导致线程立即结束,产生完整的堆栈轨迹。如果使用这个误导的基于异常的循环模式,与这个BUG相关的异常将会被扑捉到,并且被错误的解释为正常的循环终止条件。
这个例子的教训很简单:顾名思义,异常应该只用于异常的情况下,他们永远不应该用于正常的控制流。更一般的,应该优先使用标准的。容易理解的模式,而不是那么声称可以提供更好性能的、弄巧成拙的办法。即使真的能够改进性能,面对平台实现的不断改进,这么模式的性能优势也不可能一直保持。然而,由这种过度聪明的模式带来的微妙的bug,以及维护的痛苦却依然存在。
这条原则对于API设计也有启发,设计良好的API不应该被强迫他的客户端为了正常的控制流而使用异常。如果类具有“状态相关”的方法,即只有在特定的不可预知的条件下才可以被调用的方法,这个类往往也应该有个单独的“状态测试”方法,即指示是否可以调用这个状态相关的方法。例如,Iterable接口有一个状态相关的next方法,和相应的状态测试方法hasNext方法。这使得利用传统for循环对集合进行迭代的标准模式成为可能:
for(Iterator<Foo> i = collection.iterator(); i.hasNext();){
Foo foo = i.next();
}
如果Iterator缺少hasNext方法,客户端将被迫该用下面的做法:
try{
Iterator<Foo> i = collection.iterator();
while(i.hasNext()){
Foo foo = i.next();
}
}catch(NoSuchElementException e){
}
这应该非常类似与开始那个例子。除了代码繁琐且令人误解之外,这个基于异常的模式可能执行起来也比标准模式更差,并且还可能掩盖系统中其他不相关部分中bug。
另一种提供单独的状态测试方法的做法是,如果“状态相关的”方法被调用时,该对象处于不适当的状态之中,他就会返回一个可识别的值,比如null。这种方法对于Iterator而言并不适合,因为null是next方法的合法返回值。
对于“状态测试方法”和“可识别的返回值”这两种做法,有些知道原则可以帮助你在两者之中做出选择。如果对象将在缺少外部同步的情况下被并发访问,或者可被外界改变状态,使用可被识别的返回值可能很有必要的,因为在调用“状态测试”方法必须重复“状态相关”方法的工作,从性能的角度考虑,就应该使用可识别的返回值。如果其他所有方面都等同的,那么“状态测试”方法则略优于可被识别的返回值。他提供了更好的可读性,对于使用不当的情形,可能更加易于检测和改正:如果忘了去调用状态测试方法,状态相关的方法就会抛出异常,使这个bug变的很明显;如果忘了去检查可识别的返回值,这个bug就很难被发现。
总而言之,异常是为了在异常情况下使用而设计的,不要将他们用于普通的控制流,也不要编写迫使他们这么做的API。