Goingmm

 11 OutputStreamWriter out =  
 22 java.sql.Connection conn =  
 33 try { // ⑸ 
 44 　Statement stat = conn.createStatement(); 
 55 　ResultSet rs = stat.executeQuery( 
 66 　　"select uid, name from user"); 
 77 　while (rs.next()) 
 88 　{ 
 99 　　out.println("ID：" + rs.getString("uid") // ⑹ 
1010 　　　"，姓名：" + rs.getString("name")); 
1111 　} 
1212 　conn.close(); // ⑶ 
1313 　out.close(); 
1414 } 
1515 catch(Exception ex) // ⑵ 
1616 { 
1717 　ex.printStackTrace(); //⑴，⑷ 
1818 }

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

　　代碼：3行-18行。

　　仔細觀察這段代碼：如果循環內部出現了異常，會發生什么事情？我們可以得到足夠的信息判斷循環內部出錯的原因嗎？不能。我們只能知道當前正在處理的類發生了某種錯誤，但卻不能獲得任何信息判斷導致當前錯誤的原因。

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

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

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

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

　　代碼：3行-14行。

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

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

　　結論五：盡量減小try塊的體積。

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

　　代碼：7行-11行。

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

　　較為理想的處置辦法是向輸出設備寫一些信息，聲明數據的不完整性；另一種可能有效的辦法是，先緩沖要輸出的數據，準備好全部數據之后再一次性輸出。

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

          改寫后的代碼

 1OutputStreamWriter out =  
 2java.sql.Connection conn =  
 3try { 
 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") + "，姓名: " + rs.getString("name")); 
10　} 
11} 
12catch(SQLException sqlex) 
13{ 
14　out.println("警告：數據不完整"); 
15　throw new ApplicationException("讀取數據時出現SQL錯誤", sqlex); 
16} 
17catch(IOException ioex) 
18{ 
19　throw new ApplicationException("寫入數據時出現IO錯誤", ioex); 
20} 
21finally 
22{ 
23　if (conn != null) { 
24　　try { 
25　　　conn.close(); 
26　　} 
27　　catch(SQLException sqlex2) 
28　　{ 
29　　　System.err(this.getClass().getName() + ".mymethod - 不能關閉數據庫連接: " + sqlex2.toString()); 
30　　} 
31　} 
32
33　if (out != null) { 
34　　try { 
35　　　out.close(); 
36　　} 
37　　catch(IOException ioex2) 
38　　{ 
39　　　System.err(this.getClass().getName() + ".mymethod - 不能關閉輸出文件" + ioex2.toString()); 
40　　} 
41　} 
42} 

         本文的結論不是放之四海皆準的教條，有時常識和經驗才是最好的老師。如果你對自己的做法沒有百分之百的信心，務必加上詳細、全面的注釋。

　　另一方面，不要笑話這些錯誤，不妨問問你自己是否真地徹底擺脫了這些壞習慣。即使最有經驗的程序員偶爾也會誤入歧途，原因很簡單，因為它們確確實實帶來了“方便”。所有這些反例都可以看作Java編程世界的惡魔，它們美麗動人，無孔不入，時刻誘惑著你。也許有人會認為這些都屬于雞皮蒜毛的小事，不足掛齒，但請記住：勿以惡小而為之，勿以善小而不為。

2005-12-17
Goingmm  Subscription