你覺得自己是一個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）的違背 優秀編碼規範的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而能夠在實際工作中敏銳地察覺和避免這些問題。

反例之一：丟棄異常

　　 要理解其原因，我們必須回顧一下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程式設計世界的惡魔，它們美麗動人，無孔不入，時刻誘惑著你。也許有人會認為這些都屬於雞皮蒜毛的小事，不足掛齒， 但請記住：勿以惡小而為之，勿以善小而不為。