技術中(zhōng)心

　　【IT168 技術】你覺得自己是一(yī)個Java專家嗎(ma)?是否肯定自己已經全面掌握了Java的異常處理機制?在下(xià)面這段代碼中(zhōng)，你能夠迅速找出異常處理的六個問題嗎(ma)?
　　1 OutputStreamWriter out = ...
　　2 java.sql.Connection conn = ...
　　3 try { // ⑸
　　4 Statement stat = conn.createStatement();
　　5 ResultSet rs = stat.executeQuery(
　　6 select uid, name from user);
　　7 while (rs.next())
　　8 {
　　9 out.println(ID： + rs.getString(uid) // ⑹
　　10 ，姓名： + rs.getString(name));
　　11 }
　　12 conn.close(); // ⑶
　　13 out.close();
　　14 }
　　15 catch(Exception ex) // ⑵
　　16 {
　　17 ex.printStackTrace(); //⑴，⑷
　　18 }
　　作爲一(yī)個Java程序員(yuán)，你至少應該能夠找出兩個問題。但是，如果你不能找出全部六個問題，請繼續閱讀本文。
　　本文讨論的不是Java異常處理的一(yī)般性原則，因爲這些原則已經被大(dà)多數人熟知(zhī)。我(wǒ)(wǒ)們要做的是分(fēn)析各種可稱爲“反例”(anti-pattern)的違背優秀編碼規範的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而能夠在實際工(gōng)作中(zhōng)敏銳地察覺和避免這些問題。
　　反例之一(yī)：丢棄異常
　　代碼：15行-18行。
　　這段代碼捕獲了異常卻不作任何處理，可以算得上Java編程中(zhōng)的殺手。從問題出現的頻(pín)繁程度和禍害程度來看，它也許可以和C/C++程序的一(yī)個惡名遠播的問題相提并論不檢查緩沖區是否已滿。如果你看到了這種丢棄(而不是抛出)異常的情況，可以百分(fēn)之九十九地肯定代碼存在問題(在極少數情況下(xià)，這段代碼有存在的理由，但最好加上完整的注釋，以免引起别人誤解)。
　　這段代碼的錯誤在于，異常(幾乎)總是意味着某些事情不對勁了，或者說至少發生(shēng)了某些不尋常的事情，我(wǒ)(wǒ)們不應該對程序發出的求救信号保持沉默和無動于衷。調用一(yī)下(xià)printStackTrace算不上“處理異常”。不錯，調用printStackTrace對調試程序有幫助，但程序調試階段結束之後，printStackTrace就不應再在異常處理模塊中(zhōng)擔負主要責任了。
　　丢棄異常的情形非常普遍。打開(kāi)JDK的ThreadDeath類的文檔，可以看到下(xià)面這段說明：“特别地，雖然出現ThreadDeath是一(yī)種‘正常的情形’，但ThreadDeath類是Error而不是Exception的子類，因爲許多應用會捕獲所有的Exception然後丢棄它不再理睬。 ”這段話(huà)的意思是，雖然ThreadDeath代表的是一(yī)種普通的問題，但鑒于許多應用會試圖捕獲所有異常然後不予以适當的處理，所以JDK把 ThreadDeath定義成了Error的子類，因爲Error類代表的是一(yī)般的應用不應該去(qù)捕獲的嚴重問題。可見，丢棄異常這一(yī)壞習慣是如此常見，它甚至已經影響到了Java本身的設計。
　　那麽，應該怎樣改正呢?主要有四個選擇：
　　1、處理異常。針對該異常采取一(yī)些行動，例如修正問題、提醒某個人或進行其他一(yī)些處理，要根據具體(tǐ)的情形确定應該采取的動作。再次說明，調用printStackTrace算不上已經“處理好了異常”。
　　2、重新抛出異常。處理異常的代碼在分(fēn)析異常之後，認爲自己不能處理它，重新抛出異常也不失爲一(yī)種選擇。
　　3、把該異常轉換成另一(yī)種異常。大(dà)多數情況下(xià)，這是指把一(yī)個低級的異常轉換成應用級的異常(其含義更容易被用戶了解的異常)
　　4、不要捕獲異常。
　　結論一(yī)：既然捕獲了異常，就要對它進行适當的處理。不要捕獲異常之後又(yòu)把它丢棄，不予理睬。
　　反例之二：不指定具體(tǐ)的異常
　　代碼：15行。
　　許多時候人們會被這樣一(yī)種“美妙的”想法吸引：用一(yī)個catch語句捕獲所有的異常。最常見的情形就是使用catch(Exception ex)語句。但實際上，在絕大(dà)多數情況下(xià)，這種做法不值得提倡。爲什麽呢?
　　要理解其原因，我(wǒ)(wǒ)們必須回顧一(yī)下(xià)catch語句的用途。catch語句表示我(wǒ)(wǒ)們預期會出現某種異常，而且希望能夠處理該異常。異常類的作用就是告訴 Java編譯器我(wǒ)(wǒ)們想要處理的是哪一(yī)種異常。由于絕大(dà)多數異常都直接或間接從java.lang.Exception派生(shēng)，catch(Exception ex)就相當于說我(wǒ)(wǒ)們想要處理幾乎所有的異常。
　　再來看看前面的代碼例子。我(wǒ)(wǒ)們真正想要捕獲的異常是什麽呢?最明顯的一(yī)個是SQLException，這是JDBC操作中(zhōng)常見的異常。另一(yī)個可能的異常是IOException，因爲它要操作OutputStreamWriter。顯然，在同一(yī)個catch塊中(zhōng)處理這兩種截然不同的異常是不合适的。如果用兩個catch塊分(fēn)别捕獲SQLException和IOException就要好多了。這就是說，catch語句應當盡量指定具體(tǐ)的異常類型，而不應該指定涵蓋範圍太廣的Exception類。
　　另一(yī)方面，除了這兩個特定的異常，還有其他許多異常也可能出現。例如，如果由于某種原因，executeQuery返回了null，該怎麽辦?答案是讓它們繼續抛出，即不必捕獲也不必處理。實際上，我(wǒ)(wǒ)們不能也不應該去(qù)捕獲可能出現的所有異常，程序的其他地方還有捕獲異常的機會直至最後由JVM處理。
　　結論二：在catch語句中(zhōng)盡可能指定具體(tǐ)的異常類型，必要時使用多個catch。不要試圖處理所有可能出現的異常。
　　反例之三：占用資(zī)源不釋放(fàng)
　　代碼：3行-14行。
　　異常改變了程序正常的執行流程。這個道理雖然簡單，卻常常被人們忽視。如果程序用到了文件、Socket、JDBC連接之類的資(zī)源，即使遇到了異常，也要正确釋放(fàng)占用的資(zī)源。爲此，Java提供了一(yī)個簡化這類操作的關鍵詞finally。
　　finally是樣好東西：不管是否出現了異常，Finally保證在try/catch/finally塊結束之前，執行清理任務的代碼總是有機會執行。遺憾的是有些人卻不習慣使用finally。
　　當然，編寫finally塊應當多加小(xiǎo)心，特别是要注意在finally塊之内抛出的異常這是執行清理任務的最後機會，盡量不要再有難以處理的錯誤。
　　結論三：保證所有資(zī)源都被正确釋放(fàng)。充分(fēn)運用finally關鍵詞。
　　反例之四：不說明異常的詳細信息
　　代碼：3行-18行。
　　仔細觀察這段代碼：如果循環内部出現了異常，會發生(shēng)什麽事情?我(wǒ)(wǒ)們可以得到足夠的信息判斷循環内部出錯的原因嗎(ma)?不能。我(wǒ)(wǒ)們隻能知(zhī)道當前正在處理的類發生(shēng)了某種錯誤，但卻不能獲得任何信息判斷導緻當前錯誤的原因。
　　printStackTrace的堆棧跟蹤功能顯示出程序運行到當前類的執行流程，但隻提供了一(yī)些最基本的信息，未能說明實際導緻錯誤的原因，同時也不易解讀。
　　因此，在出現異常時，最好能夠提供一(yī)些文字信息，例如當前正在執行的類、方法和其他狀态信息，包括以一(yī)種更适合閱讀的方式整理和組織printStackTrace提供的信息。
　　結論四：在異常處理模塊中(zhōng)提供适量的錯誤原因信息，組織錯誤信息使其易于理解和閱讀。
　　反例之五：過于龐大(dà)的try塊
　　代碼：3行-14行。
　　經常可以看到有人把大(dà)量的代碼放(fàng)入單個try塊，實際上這不是好習慣。這種現象之所以常見，原因就在于有些人圖省事，不願花時間分(fēn)析一(yī)大(dà)塊代碼中(zhōng)哪幾行代碼會抛出異常、異常的具體(tǐ)類型是什麽。把大(dà)量的語句裝入單個巨大(dà)的try塊就象是出門旅遊時把所有日常用品塞入一(yī)個大(dà)箱子，雖然東西是帶上了，但要找出來可不容易。
　　一(yī)些新手常常把大(dà)量的代碼放(fàng)入單個try塊，然後再在catch語句中(zhōng)聲明Exception，而不是分(fēn)離(lí)各個可能出現異常的段落并分(fēn)别捕獲其異常。這種做法爲分(fēn)析程序抛出異常的原因帶來了困難，因爲一(yī)大(dà)段代碼中(zhōng)有太多的地方可能抛出Exception。
　　結論五：盡量減小(xiǎo)try塊的體(tǐ)積。
　　反例之六：輸出數據不完整
　　代碼：7行-11行。
　　不完整的數據是Java程序的隐形殺手。仔細觀察這段代碼，考慮一(yī)下(xià)如果循環的中(zhōng)間抛出了異常，會發生(shēng)什麽事情。循環的執行當然是要被打斷的，其次，catch塊會執行就這些，再也沒有其他動作了。已經輸出的數據怎麽辦?使用這些數據的人或設備将收到一(yī)份不完整的(因而也是錯誤的)數據，卻得不到任何有關這份數據是否完整的提示。對于有些系統來說，數據不完整可能比系統停止運行帶來更大(dà)的損失。
　　較爲理想的處置辦法是向輸出設備寫一(yī)些信息，聲明數據的不完整性;另一(yī)種可能有效的辦法是，先緩沖要輸出的數據，準備好全部數據之後再一(yī)次性輸出。
　　結論六：全面考慮可能出現的異常以及這些異常對執行流程的影響。
　　改寫後的代碼
　　根據上面的讨論，下(xià)面給出改寫後的代碼。也許有人會說它稍微有點?嗦，但是它有了比較完備的異常處理機制
　　OutputStreamWriter out = ...
　　java.sql.Connection conn = ...
　　try {
　　Statement stat = conn.createStatement();
　　ResultSet rs = stat.executeQuery(
　　select uid, name from user);
　　while (rs.next())
　　{
　　out.println(ID： + rs.getString(uid) + ，姓名: + rs.getString(name));
　　}
　　}
　　catch(SQLException sqlex)
　　{
　　out.println(警告：數據不完整);
　　throw new ApplicationException(讀取數據時出現SQL錯誤, sqlex);
　　}
　　catch(IOException ioex)
　　{
　　throw new ApplicationException(寫入數據時出現IO錯誤, ioex);
　　}
　　finally
　　{
　　if (conn != null) {
　　try {
　　conn.close();
　　}
　　catch(SQLException sqlex2)
　　{
　　System.err(this.getClass().getName() + .mymethod - 不能關閉數據庫連接: + sqlex2.toString());
　　}
　　}
　　if (out != null) {
　　try {
　　out.close();
　　}
　　catch(IOException ioex2)
　　{
　　System.err(this.getClass().getName() + .mymethod - 不能關閉輸出文件 + ioex2.toString());
　　}
　　}
　　}
　　本文的結論不是放(fàng)之四海皆準的教條，有時常識和經驗才是最好的老師。如果你對自己的做法沒有百分(fēn)之百的信心，務必加上詳細、全面的注釋。
　　另一(yī)方面，不要笑話(huà)這些錯誤，不妨問問你自己是否真地徹底擺脫了這些壞習慣。即使最有經驗的程序員(yuán)偶爾也會誤入歧途，原因很簡單，因爲它們确确實實帶來了“方便”。所有這些反例都可以看作Java編程世界的惡魔，它們美麗動人，無孔不入，時刻誘惑着你。也許有人會認爲這些都屬于雞皮蒜毛的小(xiǎo)事，不足挂齒，但請記住：勿以惡小(xiǎo)而爲之，勿以善小(xiǎo)而不爲。