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