計(jì)算機(jī)等考二級(jí)JAVA：Java六種異常處理的陋習(xí)

　　反例之二：不指定具體的異常

　　代碼：15行。

　　許多時(shí)候人們會(huì)被這樣一種“美妙的”想法吸引：用一個(gè)catch語(yǔ)句捕獲所有的異常。最常見(jiàn)的情形就是使用catch(Exception ex)語(yǔ)句。但實(shí)際上，在絕大多數(shù)情況下，這種做法不值得提倡。為什么呢?

　　要理解其原因，我們必須回顧一下catch語(yǔ)句的用途。catch語(yǔ)句表示我們預(yù)期會(huì)出現(xiàn)某種異常，而且希望能夠處理該異常。異常類的作用就是告訴 Java編譯器我們想要處理的是哪一種異常。由于絕大多數(shù)異常都直接或間接從java.lang.Exception派生，catch(Exception ex)就相當(dāng)于說(shuō)我們想要處理幾乎所有的異常。

　　再來(lái)看看前面的代碼例子。我們真正想要捕獲的異常是什么呢?最明顯的一個(gè)是SQLException，這是JDBC操作中常見(jiàn)的異常。另一個(gè)可能的異常是IOException，因?yàn)樗�要操作OutputStreamWriter。顯然，在同一個(gè)catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個(gè)catch塊分別捕獲SQLException和IOException就要好多了。這就是說(shuō)，catch語(yǔ)句應(yīng)當(dāng)盡量指定具體的異常類型，而不應(yīng)該指定涵蓋范圍太廣的Exception類。

　　另一方面，除了這兩個(gè)特定的異常，還有其他許多異常也可能出現(xiàn)。例如，如果由于某種原因，executeQuery返回了null，該怎么辦?答案是讓它們繼續(xù)拋出，即不必捕獲也不必處理。實(shí)際上，我們不能也不應(yīng)該去捕獲可能出現(xiàn)的所有異常，程序的其他地方還有捕獲異常的機(jī)會(huì)??直至最后由 JVM處理。

　　結(jié)論二：在catch語(yǔ)句中盡可能指定具體的異常類型，必要時(shí)使用多個(gè)catch。不要試圖處理所有可能出現(xiàn)的異常。

　　反例之三：占用資源不釋放

　　代碼：3行-14行。

　　異常改變了程序正常的執(zhí)行流程。這個(gè)道理雖然簡(jiǎn)單，卻常常被人們忽視。如果程序用到了文件、Socket、JDBC連接之類的資源，即使遇到了異常，也要正確釋放占用的資源。為此，Java提供了一個(gè)簡(jiǎn)化這類操作的關(guān)鍵詞finally。

　　finally是樣好東西：不管是否出現(xiàn)了異常，F(xiàn)inally保證在try/catch/finally塊結(jié)束之前，執(zhí)行清理任務(wù)的代碼總是有機(jī)會(huì)執(zhí)行。遺憾的是有些人卻不習(xí)慣使用finally。

　　當(dāng)然，編寫finally塊應(yīng)當(dāng)多加小心，特別是要注意在finally塊之內(nèi)拋出的異常??這是執(zhí)行清理任務(wù)的最后機(jī)會(huì)，盡量不要再有難以處理的錯(cuò)誤。

　　結(jié)論三：保證所有資源都被正確釋放。充分運(yùn)用finally關(guān)鍵詞。

　　反例之四：不說(shuō)明異常的詳細(xì)信息

　　代碼：3行-18行。

　　仔細(xì)觀察這段代碼：如果循環(huán)內(nèi)部出現(xiàn)了異常，會(huì)發(fā)生什么事情?我們可以得到足夠的信息判斷循環(huán)內(nèi)部出錯(cuò)的原因嗎?不能。我們只能知道當(dāng)前正在處理的類發(fā)生了某種錯(cuò)誤，但卻不能獲得任何信息判斷導(dǎo)致當(dāng)前錯(cuò)誤的原因。

　　printStackTrace的堆棧跟蹤功能顯示出程序運(yùn)行到當(dāng)前類的執(zhí)行流程，但只提供了一些最基本的信息，未能說(shuō)明實(shí)際導(dǎo)致錯(cuò)誤的原因，同時(shí)也不易解讀。

　　因此，在出現(xiàn)異常時(shí)，最好能夠提供一些文字信息，例如當(dāng)前正在執(zhí)行的類、方法和其他狀態(tài)信息，包括以一種更適合閱讀的方式整理和組織printStackTrace提供的信息。

　　結(jié)論四：在異常處理模塊中提供適量的錯(cuò)誤原因信息，組織錯(cuò)誤信息使其易于理解和閱讀。

　　反例之五：過(guò)于龐大的try塊

　　代碼：3行-14行。

　　經(jīng)常可以看到有人把大量的代碼放入單個(gè)try塊，實(shí)際上這不是好習(xí)慣。這種現(xiàn)象之所以常見(jiàn)，原因就在于有些人圖省事，不愿花時(shí)間分析一大塊代碼中哪幾行代碼會(huì)拋出異常、異常的具體類型是什么。把大量的語(yǔ)句裝入單個(gè)巨大的try塊就象是出門旅游時(shí)把所有日常用品塞入一個(gè)大箱子，雖然東西是帶上了，但要找出來(lái)可不容易。

　　一些新手常常把大量的代碼放入單個(gè)try塊，然后再在catch語(yǔ)句中聲明Exception，而不是分離各個(gè)可能出現(xiàn)異常的段落并分別捕獲其異常。這種做法為分析程序拋出異常的原因帶來(lái)了困難，因?yàn)橐淮蠖未�碼中有太多的地方可能拋出Exception。

　　結(jié)論五：盡量減小try塊的體積。