充分发挥异常的优点，可以提高程序的可读性、可靠性和可维护性。如果使用不当，它们也会带来负面影响。
?
某一天，如果你不走运的话，可能会碰到下面这样的代码：
class="java" name="code">try {
int i = 0;
while(true){
range[i++].climb();
}
} catch (ArrayIndexOutOfBoundsException e) {
}
? ? ? ?这段代码有什么作用？看起来根本不明显他没有真正被使用的原因是没有更好的进行优化。事实证明，作为一个要对数组元素进行遍历的实现方式，他的构思是非常拙劣的。当这个循环企图访问数组边界之外的第一个数组元素时，用抛出，捕获、忽略monospace; font-size: 1em; line-height: 1.5;">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。?
?
相关文章
