也許你會碰到如下代碼：
1.設計意圖不明顯,可讀性差
2.使用異常作為遍歷結(jié)束的條件,企圖訪問數(shù)組之外的元素,用拋出、捕獲并思、忽略數(shù)組越界異常的手段來達到終止循環(huán)的目的.
下面的標準模式,一目了然.
for (Mountaion m : range) {
m.climb();
}
為什么優(yōu)先異常的模式,而不是用行之有效標準模式呢?
可能被誤導了,企圖利用異常機制提高性能,因為jvm每次訪問數(shù)組都需要判斷下標是否越界,他們認為循環(huán)終止被隱藏了,但是在foreach循環(huán)中仍然可見，這無疑是多余的,應該避免.
上面想法有三個錯誤:
1.異常機制設計的初衷是用來處理不正常的情況,所以JVM很少對它們進行優(yōu)化.
2.代碼放在try..catch中反而阻止jvm本身要執(zhí)行的某些特定優(yōu)化
3.對數(shù)組進行遍歷的標準模式并不會導致冗余的檢查.
現(xiàn)在jvm實現(xiàn),基于異常模式要比標準模式慢得多.
基于異常模式模糊了代碼意圖,降低它的性能,并且無法保證正常工作!如果出現(xiàn)bug,模式可能會悄悄失效,并且掩蓋這個bug,增加調(diào)試過程的復雜性.假設循環(huán)中調(diào)用某個方法執(zhí)行不相關(guān)數(shù)組的越界異常訪問,使用合理模式,可以獲得完整的異常鏈,如果基于異常模式,這個bug會捕獲到,但是被誤解為正常循環(huán)終止條件. 案例的經(jīng)驗是,異常只應該使用在異常情況下,它們永遠不應該用于正常的控制流中.
優(yōu)先使用標準的,易于理解的模式,而不是那些聲稱可以提高性能,弄巧成拙的方法.即使可以提高性能,面對平臺不斷改進,這種基于異常的模式的優(yōu)勢不可能一直存在,而維護的痛苦卻永遠存在.
總而言之淹办，異常是為了在異常情況下使用而設計的矾芙。不要將它們用于普通的控制流，也不要編寫破事它們這么做的API普监。
