Effective Java学习(异常)之——只针对异常的情况才使用异常

充分发挥异常的优点，可以提高程序的可读性、可靠性和可维护性。如果使用不当，它们也会带来负面影响。

 

某一天，如果你不走运的话，可能会碰到下面这样的代码：

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。