六種異常處理的陋習

在下面這段代碼中,你能夠迅速找出異常處理的六個問題嗎?

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 }

反例之一:丟棄異常 代碼:15行-18行。 

    這段代碼捕獲了異常卻不作任何處理,可以算得上Java編程中的殺手。調用一下printStackTrace算不上“處理異常”,只對調試程序有幫助。那麼,應該怎樣改正呢?主要有四個選擇:

  1、處理異常。針對該異常採取一些行動,例如修正問題、提醒某個人或進行其他一些處理,要根據 具體的情形確定應該採取的動作。

  2、重新拋出異常。處理異常的代碼在分析異常之後,認爲自己不能處理它,重新拋出異常也不失爲 一種選擇。

  3、把該異常轉換成另一種異常。大多數情況下,這是指把一個低級的異常轉換成應用級的異常。

  4、不要捕獲異常。

  結論一:既然捕獲了異常,就要對它進行適當的處理。不要捕獲異常之後又把它丟棄,不予理睬。   反例之二:不指定具體的異常 代碼:15行。

  catch語句表示我們預期會出現某種異常,而且希望能夠處理該異常。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常。再來看看前面的代碼例子。我們真正想要捕獲的異常是SQLException,這是JDBC操作中常見的異常。另一個可能的異常是IOException,因爲它要操作OutputStreamWriter。顯然,在同一個catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個catch塊分別捕獲SQLException和IOException就要好多了。這就是說,catch語句應當儘量指定具體的異常類型,而不應該指定涵蓋範圍太廣的Exception類。

  另一方面,除了這兩個特定的異常,還有其他許多異常也可能出現。例如,如果由於某種原因, executeQuery返回了null,該怎麼辦?答案是讓它們繼續拋出,即不必捕獲也不必處理。實際上,我們不 能也不應該去捕獲可能出現的所有異常,程序的其他地方還有捕獲異常的機會??直至最後由JVM處理。

  結論二:在catch語句中儘可能指定具體的異常類型,必要時使用多個catch。不要試圖處理所有可能 出現的異常。

  反例之三:佔用資源不釋放 代碼:3行-14行。

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

  結論三:保證所有資源都被正確釋放。充分運用finally關鍵詞。

 反例之四:不說明異常的詳細信息 代碼:3行-18行。

   仔細觀察這段代碼:如果循環內部出現了異常,會發生什麼事情?我們可以得到足夠的信息判斷循環 內部出錯的原因嗎?不能。

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

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

   結論四:在異常處理模塊中提供適量的錯誤原因信息,組織錯誤信息使其易於理解和閱讀。

   反例之五:過於龐大的try塊 代碼:3行-14行。

   經常可以看到有人把大量的代碼放入單個try塊,實際上這不是好習慣。這種現象之所以常見,原因 就在於有些人圖省事,不願花時間分析一大塊代碼中哪幾行代碼會拋出異常、異常的具體類型是什麼。一些新手常常把大量的代碼放入單個try塊,然後再在catch語句中聲明Exception,而不是分離各個可能出現異常的段落並分別捕獲其異常。這種做法爲分析程序拋出異常的原因帶來了困難,因爲一大段代 碼中有太多的地方可能拋出Exception。

  結論五:儘量減小try塊的體積。

   反例之六:輸出數據不完整 代碼:7行-11行。

   不完整的數據是Java程序的隱形殺手。較爲理想的處置辦法是向輸出設備寫一些信息,聲明數據的不完整性;另一種可能有效的辦法是,先緩衝要輸出的數據,準備好全部數據之後再一次性輸出。

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

   改寫後的代碼

 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());   }

 }

}


來自:http://blog.csdn.net/yakihappy/article/details/4167572

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章