這篇文章主要介紹了Java異常處理之陋習(xí)展播的示例分析，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

成都創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：做網(wǎng)站、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的日土網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

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 }







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



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



反例之一：丟棄異常



代碼：15行-18行。



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



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



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



那么，應(yīng)該怎樣改正呢？主要有四個(gè)選擇：



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


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



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



4、不要捕獲異常。



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



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



代碼：15行。



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



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



再來(lái)看看前面的代碼例子。我們真正想要捕獲的異常是什么呢？最明顯的一個(gè)是SQLException，這是JdbC操作中常見的異常。另一個(gè)可能的異常是IOException，因?yàn)樗僮鱋utputStreamWriter。顯然，在同一個(gè)catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個(gè)catch塊分別捕獲SQLException和IOException就要好多了。這就是說(shuō)，catch語(yǔ)句應(yīng)當(dāng)盡量指定具體的異常類型，而不應(yīng)該指定涵蓋范圍太廣的Exception類。



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



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



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



代碼：3行-14行。



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



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



當(dāng)然，編寫finally塊應(yīng)當(dāng)多加小心，特別是要注意在finally塊之內(nèi)拋出的異?！@是執(zhí)行清理任務(wù)的最后機(jī)會(huì)，盡量不要再有難以處理的錯(cuò)誤。



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



反例之四：不說(shuō)明異常的詳細(xì)信息



代碼：3行-18行。



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



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



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



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



反例之五：過(guò)于龐大的try塊



代碼：3行-14行。



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



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



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



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



代碼：7行-11行。



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



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



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



改寫后的代碼



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



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("警告：數(shù)據(jù)不完整");

throw new ApplicationException(

"讀取數(shù)據(jù)時(shí)出現(xiàn)SQL錯(cuò)誤", sqlex);

}

catch(IOException ioex)

{

throw new ApplicationException(

"寫入數(shù)據(jù)時(shí)出現(xiàn)IO錯(cuò)誤", ioex);

}

finally

{

if (conn != null) {

try {

conn.close();

}

catch(SQLException sqlex2)

{

System.err(this.getClass().getName() +

".mymethod - 不能關(guān)閉數(shù)據(jù)庫(kù)連接: " +

sqlex2.toString());

}

}



if (out != null) {

try {

out.close();

}

catch(IOException ioex2)

{

System.err(this.getClass().getName() +

".mymethod - 不能關(guān)閉輸出文件" +

ioex2.toString());

}

}

}

 

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“Java異常處理之陋習(xí)展播的示例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!

名稱欄目：Java異常處理之陋習(xí)展播的示例分析
瀏覽地址：http://m.rwnh.cn/article6/jgpjig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站排名、做網(wǎng)站、網(wǎng)站收錄、網(wǎng)站設(shè)計(jì)、靜態(tài)網(wǎng)站

廣告

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