也许你会碰到如下代码：
1.设计意图不明显,可读性差
2.使用异常作为遍历结束的条件,企图访问数组之外的元素,用抛出、捕获、忽略数组越界异常的手段来达到终止循环的目的.
下面的标准模式,一目了然.
for (Mountaion m : range) {
m.climb();
}
为什么优先异常的模式,而不是用行之有效标准模式呢?
可能被误导了,企图利用异常机制提高性能,因为jvm每次访问数组都需要判断下标是否越界,他们认为循环终止被隐藏了,但是在foreach循环中仍然可见，这无疑是多余的,应该避免.
上面想法有三个错误:
1.异常机制设计的初衷是用来处理不正常的情况,所以JVM很少对它们进行优化.
2.代码放在try..catch中反而阻止jvm本身要执行的某些特定优化
3.对数组进行遍历的标准模式并不会导致冗余的检查.
现在jvm实现,基于异常模式要比标准模式慢得多.
基于异常模式模糊了代码意图,降低它的性能,并且无法保证正常工作!如果出现bug,模式可能会悄悄失效,并且掩盖这个bug,增加调试过程的复杂性.假设循环中调用某个方法执行不相关数组的越界异常访问,使用合理模式,可以获得完整的异常链,如果基于异常模式,这个bug会捕获到,但是被误解为正常循环终止条件. 案例的经验是,异常只应该使用在异常情况下,它们永远不应该用于正常的控制流中.
优先使用标准的,易于理解的模式,而不是那些声称可以提高性能,弄巧成拙的方法.即使可以提高性能,面对平台不断改进,这种基于异常的模式的优势不可能一直存在,而维护的痛苦却永远存在.
总而言之，异常是为了在异常情况下使用而设计的。不要将它们用于普通的控制流，也不要编写破事它们这么做的API。
