這期內(nèi)容當中小編將會給大家?guī)碛嘘P怎樣解析Java的異常處理機制，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

創(chuàng)新互聯(lián)建站于2013年創(chuàng)立，先為寧河等服務建站，寧河等地企業(yè)，進行企業(yè)商務咨詢服務。為寧河企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。

你覺得自己是一個Java專家嗎?是否肯定自己已經(jīng)全面掌握了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"));   }   conn.close(); // ⑶   out.close();   }   catch(Exception ex) // ⑵   {   ex.printStackTrace(); //⑴，⑷   }

作為一個Java程序員，你至少應該能夠找出兩個問題。但是，如果你不能找出全部六個問題，請繼續(xù)閱讀本文。

討論的不是Java異常處理的一般性原則，因為這些原則已經(jīng)被大多數(shù)人熟知。我們要做的是分析各種可稱為“反例”(anti-pattern)的違背優(yōu)秀編碼規(guī)范的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而能夠在實際工作中敏銳地察覺和避免這些問題。

反例之一：丟棄異常

代碼：15行-18行。

這段代碼捕獲了異常卻不作任何處理，可以算得上Java編程中的殺手。從問題出現(xiàn)的頻繁程度和禍害程度來看，它也許可以和C/C++程序的一個惡名遠播的問題相提并論??不檢查緩沖區(qū)是否已滿。如果你看到了這種丟棄(而不是拋出)異常的情況，可以百分之九十九地肯定代碼存在問題(在極少數(shù)情況下，這段代碼有存在的理由，但***加上完整的注釋，以免引起別人誤解)。

這段代碼的錯誤在于，異常(幾乎)總是意味著某些事情不對勁了，或者說至少發(fā)生了某些不尋常的事情，我們不應該對程序發(fā)出的求救信號保持沉默和無動于衷。調(diào)用一下printStackTrace算不上“處理異?！薄２诲e，調(diào)用printStackTrace對調(diào)試程序有幫助，但程序調(diào)試階段結(jié)束之后，printStackTrace就不應再在異常處理模塊中擔負主要責任了。

丟棄異常的情形非常普遍。打開JDK的ThreadDeath類的文檔，可以看到下面這段說明：“特別地，雖然出現(xiàn)ThreadDeath是一種‘正常的情形’，但ThreadDeath類是Error而不是Exception的子類，因為許多應用會捕獲所有的Exception然后丟棄它不再理睬?！边@段話的意思是，雖然ThreadDeath代表的是一種普通的問題，但鑒于許多應用會試圖捕獲所有異常然后不予以適當?shù)奶幚?，所以JDK把ThreadDeath定義成了Error的子類，因為Error類代表的是一般的應用不應該去捕獲的嚴重問題?？梢?，丟棄異常這一壞習慣是如此常見，它甚至已經(jīng)影響到了Java本身的設計。

那么，應該怎樣改正呢?主要有四個選擇：

1、處理異常。針對該異常采取一些行動，例如修正問題、提醒某個人或進行其他一些處理，要根據(jù)具體的情形確定應該采取的動作。再次說明，調(diào)用printStackTrace算不上已經(jīng)“處理好了異?！?。

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

3、把該異常轉(zhuǎn)換成另一種異常。大多數(shù)情況下，這是指把一個低級的異常轉(zhuǎn)換成應用級的異常(其含義更容易被用戶了解的異常)。

4、不要捕獲異常。

結(jié)論一：既然捕獲了異常，就要對它進行適當?shù)奶幚?。不要捕獲異常之后又把它丟棄，不予理睬。

反例之二：不指定具體的異常

代碼：15行。

許多時候人們會被這樣一種“美妙的”想法吸引：用一個catch語句捕獲所有的異常。最常見的情形就是使用catch(Exception ex)語句。但實際上，在絕大多數(shù)情況下，這種做法不值得提倡。為什么呢?

要理解其原因，我們必須回顧一下catch語句的用途。catch語句表示我們預期會出現(xiàn)某種異常，而且希望能夠處理該異常。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常。由于絕大多數(shù)異常都直接或間接從java.lang.Exception派生，catch(Exception ex)就相當于說我們想要處理幾乎所有的異常。

再來看看前面的代碼例子。我們真正想要捕獲的異常是什么呢?最明顯的一個是SQLException，這是JDBC操作中常見的異常。另一個可能的異常是IOException，因為它要操作OutputStreamWriter.顯然，在同一個catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個catch塊分別捕獲SQLException和IOException就要好多了。這就是說，catch語句應當盡量指定具體的異常類型，而不應該指定涵蓋范圍太廣的Exception類。

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

結(jié)論二：在catch語句中盡可能指定具體的異常類型，必要時使用多個catch.不要試圖處理所有可能出現(xiàn)的異常。

反例之三：占用資源不釋放

代碼：3行-14行。

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

finally是樣好東西：不管是否出現(xiàn)了異常，F(xiàn)inally保證在try/catch/finally塊結(jié)束之前，執(zhí)行清理任務的代碼總是有機會執(zhí)行。遺憾的是有些人卻不習慣使用finally.

當然，編寫finally塊應當多加小心，特別是要注意在finally塊之內(nèi)拋出的異常??這是執(zhí)行清理任務的***機會，盡量不要再有難以處理的錯誤。

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

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

代碼：3行-18行。

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

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

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

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

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

代碼：3行-14行。

經(jīng)?？梢钥吹接腥税汛罅康拇a放入單個try塊，實際上這不是好習慣。這種現(xiàn)象之所以常見，原因就在于有些人圖省事，不愿花時間分析一大塊代碼中哪幾行代碼會拋出異常、異常的具體類型是什么。把大量的語句裝入單個巨大的try塊就象是出門旅游時把所有日常用品塞入一個大箱子，雖然東西是帶上了，但要找出來可不容易。

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

結(jié)論五：盡量減小try塊的體積。

反例之六：輸出數(shù)據(jù)不完整

代碼：7行-11行。

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

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

結(jié)論六：全面考慮可能出現(xiàn)的異常以及這些異常對執(zhí)行流程的影響。

改寫后的代碼

根據(jù)上面的討論，下面給出改寫后的代碼。也許有人會說它稍微有點?嗦，但是它有了比較完備的異常處理機制。

catch(SQLException sqlex)   {   out.println("警告：數(shù)據(jù)不完整");   throw new ApplicationException("讀取數(shù)據(jù)時出現(xiàn)SQL錯誤", sqlex);   }   catch(IOException ioex)   {   throw new ApplicationException("寫入數(shù)據(jù)時出現(xiàn)IO錯誤", ioex);   }   finally  {   if (conn != null) {   try {   conn.close();   }   catch(SQLException sqlex2)   {   System.err(this.getClass().getName() + ".mymethod - 不能關閉數(shù)據(jù)庫連   接:　" + sqlex2.toString());   }   }   if (out != null) {   try {   out.close();   }   catch(IOException ioex2)   {   System.err(this.getClass().getName() + ".mymethod - 不能關閉輸出文件"  + ioex2.toString());   }   }   }

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

上述就是小編為大家分享的怎樣解析Java的異常處理機制了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章題目：怎樣解析Java的異常處理機制
文章源于：http://aaarwkj.com/article14/jeggge.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設計、網(wǎng)站策劃、營銷型網(wǎng)站建設、軟件開發(fā)、手機網(wǎng)站建設、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)