国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 學院 > 開發設計 > 正文

Java異常處理之陋習展播

2019-11-18 11:50:30
字體：大 中 小
來源：轉載
供稿：網友

　　你覺得自己是一個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.　　
　　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塊會執行——就這些，再也沒有其他動作了。已經輸出的數據怎么辦？使用這些數據的人或設備將收到一份不完整的（因而也是錯誤的）數據，卻得不到任何有關這份數據是否完整的提示。對于有些系統來說，數據不完整可能比系統停止運行帶來更大的損失。
　　
　　
　　
　　　　較為理想的處置辦法是向輸出設備寫一些信息，聲明數據的不完整性；另一種可能有效的辦法是，先緩沖要輸出的數據，預備好全部數據之后再一次性輸出。
　　

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板： 哈尔滨市| 林州市| 林口县| 名山县| 榆林市| 西乌珠穆沁旗| 甘洛县| 雷州市| 五河县| 都昌县| 乌苏市| 滦平县| 巴东县| 航空| 鹿泉市| 新巴尔虎左旗| 舞钢市| 忻州市| 工布江达县| 纳雍县| 郁南县| 当涂县| 马公市| 石城县| 三门峡市| 嘉义县| 长子县| 万年县| 桂东县| 米易县| 德江县| 萨嘎县| 高邮市| 乐平市| 永修县| 南澳县| 澜沧| 漳浦县| 岳池县| 榕江县| 岳池县|