一篇不錯的講解Java異常的文章(轉載)原做者已無法考證

六種異常處理的陋習

你以爲本身是一個Java專家嗎？是否確定本身已經全面掌握了Java的異常處理機制？在下面這段代碼中，你可以迅速找出異常處理的六個問題嗎？ 


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 }

　　做爲一個Java程序員，你至少應該可以找出兩個問題。可是，若是你不能找出所有六個問題，請繼續閱讀本文。 

　　本文討論的不是Java異常處理的通常性原則，由於這些原則已經被大多數人熟知。咱們要作的是分析各類可稱爲「反例」（anti-pattern）的違背優秀編碼規範的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而可以在實際工做中敏銳地察覺和避免這些問題。 

　　反例之一：丟棄異常 

　　代碼：15行-18行。 

　　這段代碼捕獲了異常卻不做任何處理，能夠算得上Java編程中的殺手。從問題出現的頻繁程度和禍害程度來看，它也許能夠和C/C++程序的一個惡名遠播的問題相提並論??不檢查緩衝區是否已滿。若是你看到了這種丟棄（而不是拋出）異常的狀況，能夠百分之九十九地確定代碼存在問題（在極少數狀況下，這段代碼有存在的理由，但最好加上完整的註釋，以避免引發別人誤解）。 

　　這段代碼的錯誤在於，異常（幾乎）老是意味着某些事情不對勁了，或者說至少發生了某些不尋常的事情，咱們不該該對程序發出的求救信號保持沉默和無動於衷。調用一下printStackTrace算不上「處理異常」。不錯，調用printStackTrace對調試程序有幫助，但程序調試階段結束以後，printStackTrace就不該再在異常處理模塊中擔負主要責任了。 

　　丟棄異常的情形很是廣泛。打開JDK的ThreadDeath類的文檔，能夠看到下面這段說明：「特別地，雖然出現ThreadDeath是一種‘正常的情形’，但ThreadDeath類是Error而不是Exception的子類，由於許多應用會捕獲全部的Exception而後丟棄它再也不理睬。」這段話的意思是，雖然ThreadDeath表明的是一種普通的問題，但鑑於許多應用會試圖捕獲全部異常而後不予以適當的處理，因此JDK把ThreadDeath定義成了Error的子類，由於Error類表明的是通常的應用不該該去捕獲的嚴重問題。可見，丟棄異常這一壞習慣是如此常見，它甚至已經影響到了Java自己的設計。 

　　那麼，應該怎樣改正呢？主要有四個選擇： 

　　一、處理異常。針對該異常採起一些行動，例如修正問題、提醒某我的或進行其餘一些處理，要根據具體的情形肯定應該採起的動做。再次說明，調用printStackTrace算不上已經「處理好了異常」。 

　　二、從新拋出異常。處理異常的代碼在分析異常以後，認爲本身不能處理它，從新拋出異常也不失爲一種選擇。 

　　三、把該異常轉換成另外一種異常。大多數狀況下，這是指把一個低級的異常轉換成應用級的異常（其含義更容易被用戶瞭解的異常）。 

　　四、不要捕獲異常。 

　　結論一：既然捕獲了異常，就要對它進行適當的處理。不要捕獲異常以後又把它丟棄，不予理睬。 

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

　　代碼：15行。 

　　許多時候人們會被這樣一種「美妙的」想法吸引：用一個catch語句捕獲全部的異常。最多見的情形就是使用catch(Exception ex)語句。但實際上，在絕大多數狀況下，這種作法不值得提倡。爲何呢？ 

　　要理解其緣由，咱們必須回顧一下catch語句的用途。catch語句表示咱們預期會出現某種異常，並且但願可以處理該異常。異常類的做用就是告訴Java編譯器咱們想要處理的是哪種異常。因爲絕大多數異常都直接或間接從java.lang.Exception派生，catch(Exception ex)就至關於說咱們想要處理幾乎全部的異常。 

　　再來看看前面的代碼例子。咱們真正想要捕獲的異常是什麼呢？最明顯的一個是SQLException，這是JDBC操做中常見的異常。另外一個可能的異常是IOException，由於它要操做OutputStreamWriter。顯然，在同一個catch塊中處理這兩種大相徑庭的異常是不合適的。若是用兩個catch塊分別捕獲SQLException和IOException就要好多了。這就是說，catch語句應當儘可能指定具體的異常類型，而不該該指定涵蓋範圍太廣的Exception類。 

　　另外一方面，除了這兩個特定的異常，還有其餘許多異常也可能出現。例如，若是因爲某種緣由，executeQuery返回了null，該怎麼辦？答案是讓它們繼續拋出，即沒必要捕獲也沒必要處理。實際上，咱們不能也不該該去捕獲可能出現的全部異常，程序的其餘地方還有捕獲異常的機會??直至最後由JVM處理。 

　　結論二：在catch語句中儘量指定具體的異常類型，必要時使用多個catch。不要試圖處理全部可能出現的異常。 

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

　　代碼：3行-14行。 

　　異常改變了程序正常的執行流程。這個道理雖然簡單，卻經常被人們忽視。若是程序用到了文件、Socket、JDBC鏈接之類的資源，即便遇到了異常，也要正確釋放佔用的資源。爲此，Java提供了一個簡化這類操做的關鍵詞finally。 

　　finally是樣好東西：無論是否出現了異常，Finally保證在try/catch/finally塊結束以前，執行清理任務的代碼老是有機會執行。遺憾的是有些人卻不習慣使用finally。 

　　固然，編寫finally塊應當多加當心，特別是要注意在finally塊以內拋出的異常??這是執行清理任務的最後機會，儘可能不要再有難以處理的錯誤。 

　　結論三：保證全部資源都被正確釋放。充分運用finally關鍵詞。

反例之四：不說明異常的詳細信息 

　　代碼：3行-18行。 

　　仔細觀察這段代碼：若是循環內部出現了異常，會發生什麼事情？咱們能夠獲得足夠的信息判斷循環內部出錯的緣由嗎？不能。咱們只能知道當前正在處理的類發生了某種錯誤，但卻不能得到任何信息判斷致使當前錯誤的緣由。 

　　printStackTrace的堆棧跟蹤功能顯示出程序運行到當前類的執行流程，但只提供了一些最基本的信息，未能說明實際致使錯誤的緣由，同時也不易解讀。 

　　所以，在出現異常時，最好可以提供一些文字信息，例如當前正在執行的類、方法和其餘狀態信息，包括以一種更適合閱讀的方式整理和組織printStackTrace提供的信息。

　　結論四：在異常處理模塊中提供適量的錯誤緣由信息，組織錯誤信息使其易於理解和閱讀。 

　　反例之五：過於龐大的try塊 

　　代碼：3行-14行。 

　　常常能夠看到有人把大量的代碼放入單個try塊，實際上這不是好習慣。這種現象之因此常見，緣由就在於有些人圖省事，不肯花時間分析一大塊代碼中哪幾行代碼會拋出異常、異常的具體類型是什麼。把大量的語句裝入單個巨大的try塊就象是出門旅遊時把全部平常用品塞入一個大箱子，雖然東西是帶上了，但要找出來可不容易。 

　　一些新手經常把大量的代碼放入單個try塊，而後再在catch語句中聲明Exception，而不是分離各個可能出現異常的段落並分別捕獲其異常。這種作法爲分析程序拋出異常的緣由帶來了困難，由於一大段代碼中有太多的地方可能拋出Exception。 

　　結論五：儘可能減少try塊的體積。 

　　反例之六：輸出數據不完整 

　　代碼：7行-11行。 

　　不完整的數據是Java程序的隱形殺手。仔細觀察這段代碼，考慮一下若是循環的中間拋出了異常，會發生什麼事情。循環的執行固然是要被打斷的，其次，catch塊會執行??就這些，再也沒有其餘動做了。已經輸出的數據怎麼辦？使用這些數據的人或設備將收到一份不完整的（於是也是錯誤的）數據，卻得不到任何有關這份數據是否完整的提示。對於有些系統來講，數據不完整可能比系統中止運行帶來更大的損失。 

　　較爲理想的處置辦法是向輸出設備寫一些信息，聲明數據的不完整性；另外一種可能有效的辦法是，先緩衝要輸出的數據，準備好所有數據以後再一次性輸出。 

　　結論六：全面考慮可能出現的異常以及這些異常對執行流程的影響。 

　　改寫後的代碼 

　　根據上面的討論，下面給出改寫後的代碼。也許有人會說它稍微有點?嗦，可是它有了比較完備的異常處理機制。 

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()); 
　　} 
　} 
}
　　本文的結論不是放之四海皆準的教條，有時常識和經驗纔是最好的老師。若是你對本身的作法沒有百分之百的信心，務必加上詳細、全面的註釋。 

　　另外一方面，不要笑話這些錯誤，不妨問問你本身是否真地完全擺脫了這些壞習慣。即便最有經驗的程序員偶爾也會誤入歧途，緣由很簡單，由於它們確確實實帶來了「方便」。全部這些反例均可以看做Java編程世界的惡魔，它們美麗動人，無孔不入，時刻誘惑着你。也許有人會認爲這些都屬於雞皮蒜毛的小事，不足掛齒，但請記住：勿以惡小而爲之，勿以善小而不爲。