Sitemap" content="www.duozhankeji.com">
全國免費熱線:
評點六種Java異常處理的陋習
作者:admin 点击:19925次 日期:2015-06-04
字號::T | T
  【IT168 技术】你觉得自己是一个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本身的设计。
  那麽,應該怎樣改正呢?主要有四個選擇:
  1、處理異常。針對該異常采取一些行動,例如修正問題、提醒某個人或進行其他一些處理,要根據具體的情形確定應該采取的動作。再次說明,調用printStackTrace算不上已經“處理好了異常”。
  2、重新抛出異常。處理異常的代碼在分析異常之後,認爲自己不能處理它,重新抛出異常也不失爲一種選擇。
  3、把該異常轉換成另一種異常。大多數情況下,這是指把一個低級的異常轉換成應用級的異常(其含義更容易被用戶了解的異常)
  4、不要捕獲異常。
  結論一:既然捕獲了異常,就要對它進行適當的處理。不要捕獲異常之後又把它丟棄,不予理睬。
  反例之二:不指定具體的異常
  代碼: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編程世界的惡魔,它們美麗動人,無孔不入,時刻誘惑著你。也許有人會認爲這些都屬于雞皮蒜毛的小事,不足挂齒,但請記住:勿以惡小而爲之,勿以善小而不爲。

發表評論

昵稱 * 驗證碼 * 驗證碼
上一篇: 分布式MySQL數據庫TDSQL架構分析
下一篇: 優秀程序員眼中的整潔代碼

資質證書

CMMI Ⅲ APPRAISAL ID:30062
ISO9001:08915Q20090ROS
ISO27001:04817I20037R0S
高新技術企業:GR201753000141
網站问题免费诊断

电子商务三位一体發展戰略

技術研發

業務培训

實戰運營

戰略布局