e.printStackTrace();
本文從Java異常最基本的概念、語法開始講述了Java異常處理的基本知識,分析了Java異常體系結構,對比Spring的異常處理框 架,闡述了異常處理的基本原則。并且作者提出了自己處理一個大型應用系統異常的思想,并通過設計一個異常處理的框架來論述此思想。
一、 異常的概念和Java異常體系結構
異常是程序運行過程中出現的錯誤。本文主要講授的是Java語言的異常處理。Java語言的異常處理框架,是Java語言健壯性的一個重要體現。
Java把異常當作對象來處理,并定義一個基類java.lang.Throwable作為所有異常的超類。在Java API中已經定義了許多異常類,這些異常類分為兩大類,錯誤Error和異常Exception。Java異常體系結構呈樹狀,其層次結構圖如圖 1所示:
圖 1 Java異常體系結構
Thorwable類所有異常和錯誤的超類,有兩個子類Error和Exception,分別表示錯誤和異常。其中異常類Exception又分為 運行時異常(RuntimeException)和非運行時異常,這兩種異常有很大的區別,也稱之為不檢查異常(Unchecked Exception)和檢查異常(Checked Exception)。下面將詳細講述這些異常之間的區別與聯系:
1、Error與Exception Error是程序無法處理的錯誤,比如OutOfMemoryError、ThreadDeath等。這些異常發生時,Java虛擬機(JVM)一般會選擇線程終止。
Exception是程序本身可以處理的異常,這種異常分兩大類運行時異常和非運行時異常。程序中應當盡可能去處理這些異常。
2、運行時異常和非運行時異常
運行時異常都是RuntimeException類及其子類異常,如NullPointerException、 IndexOutOfBoundsException等,這些異常是不檢查異常,程序中可以選擇捕獲處理,也可以不處理。這些異常一般是由程序邏輯錯誤引 起的,程序應該從邏輯角度盡可能避免這類異常的發生。
非運行時異常是RuntimeException以外的異常,類型上都屬于Exception類及其子類。從程序語法角度講是必須進行處理的異常,如果不 處理,程序就不能編譯通過。如IOException、SQLException等以及用戶自定義的Exception異常,一般情況下不自定義檢查異 常。
二、 異常的捕獲和處理
Java異常的捕獲和處理是一個不容易把握的事情,如果處理不當,不但會讓程序代碼的可讀性大大降低,而且導致系統性能低下,甚至引發一些難以發現的錯誤。
Java異常處理涉及到五個關鍵字,分別是:try、catch、finally、throw、throws。下面將驟一介紹,通過認識這五個關鍵字,掌握基本異常處理知識。
1、 異常處理的基本語法
在java中,異常處理的完整語法是:
try{
//(嘗試運行的)程序代碼
}catch(異常類型 異常的變量名){
//異常處理代碼
}finally{
//異常發生,方法返回之前,總是要執行的代碼
}
以上語法有三個代碼塊:
try語句塊,表示要嘗試運行代碼,try語句塊中代碼受異常監控,其中代碼發生異常時,會拋出異常對象。
catch語句塊會捕獲try代碼塊中發生的異常并在其代碼塊中做異常處理,catch語句帶一個Throwable類型的參數,表示可捕獲異常類型。當 try中出現異常時,catch會捕獲到發生的異常,并和自己的異常類型匹配,若匹配,則執行catch塊中代碼,并將catch塊參數指向所拋的異常對 象。catch語句可以有多個,用來匹配多個中的一個異常,一旦匹配上后,就不再嘗試匹配別的catch塊了。通過異常對象可以獲取異常發生時完整的 JVM堆棧信息,以及異常信息和異常發生的原因等。
finally語句塊是緊跟catch語句后的語句塊,這個語句塊總是會在方法返回前執行,而不管是否try語句塊是否發生異常。并且這個語句塊總是在方 法返回前執行。目的是給程序一個補救的機會。這樣做也體現了Java語言的健壯性。 2、 try、catch、finally三個語句塊應注意的問題
第一、try、catch、finally三個語句塊均不能單獨使用,三者可以組成 try...catch...finally、try...catch、try...finally三種結構,catch語句可以有一個或多個,finally語句最多一個。
第二、try、catch、finally三個代碼塊中變量的作用域為代碼塊內部,分別獨立而不能相互訪問。如果要在三個塊中都可以訪問,則需要將變量定義到這些塊的外面。
第三、多個catch塊時候,只會匹配其中一個異常類并執行catch塊代碼,而不會再執行別的catch塊,并且匹配catch語句的順序是由上到下。
3、throw、throws關鍵字
throw關鍵字是用于方法體內部,用來拋出一個Throwable類型的異常。如果拋出了檢查異常,則還應該在方法頭部聲明方法可能拋出的異常類型。該 方法的調用者也必須檢查處理拋出的異常。如果所有方法都層層上拋獲取的異常,最終JVM會進行處理,處理也很簡單,就是打印異常消息和堆棧信息。如果拋出 的是Error或RuntimeException,則該方法的調用者可選擇處理該異常。有關異常的轉譯會在下面說明。 throws關鍵字用于方法體外部的方法聲明部分,用來聲明方法可能會拋出某些異常。僅當拋出了檢查異常,該方法的調用者才必須處理或者重新拋出該異常。 當方法的調用者無力處理該異常的時候,應該繼續拋出,而不是囫圇吞棗一般在catch塊中打印一下堆棧信息做個勉強處理。下面給出一個簡單例子,看看如何 使用這兩個關鍵字:
public static void test3() throws Exception{
//拋出一個檢查異常
throw new Exception("方法test3中的Exception");
}
3、 Throwable類中的常用方法
getCause():返回拋出異常的原因。如果 cause 不存在或未知,則返回 null。
getMessage():返回異常的消息信息。
printStackTrace():對象的堆棧跟蹤輸出至錯誤輸出流,作為字段 System.err 的值。
三、 異常處理的一般原則
1、 能處理就早處理,拋出不去還不能處理的就想法消化掉或者轉換為RuntimeException處理。因為對于一個應用系統來說,拋出大量異常是有問題的,應該從程序開發角度盡可能的控制異常發生的可能。
2、 對于檢查異常,如果不能行之有效的處理,還不如轉換為RuntimeException拋出。這樣也讓上層的代碼有選擇的余地――可處理也可不處理。
3、 對于一個應用系統來說,應該有自己的一套異常處理框架,這樣當異常發生時,也能得到統一的處理風格,將優雅的異常信息反饋給用戶。
四、 異常的轉譯與異常鏈
1、異常轉譯的原理
所謂的異常轉譯就是將一種異常轉換另一種新的異常,也許這種新的異常更能準確表達程序發生異常。
在Java中有個概念就是異常原因,異常原因導致當前拋出異常的那個異常對象,幾乎所有帶異常原因的異常構造方法都使用Throwable類型做參數,這 也就為異常的轉譯提供了直接的支持,因為任何形式的異常和錯誤都是Throwable的子類。比如將SQLException轉換為另外一個新的異常 DAOException,可以這么寫:
先自定義一個異常DAOException:
public class DAOException extends RuntimeException {
//(省略了部分代碼)
public DAOException(String message, Throwable cause) {
super(message, cause);
}
}
比如有一個SQLException類型的異常對象e,要轉換為DAOException,可以這么寫:
DAOException daoEx = new DAOException ( "SQL異常", e);
異常轉譯是針對所有繼承Throwable超類的類而言的,從編程的語法角度講,其子類之間都可以相互轉換。但是,從合理性和系統設計角度考慮,可將異常 分為三類:Error、Exception、RuntimeException,筆者認為,合理的轉譯關系圖應該如圖 2:
圖 2 異常轉譯
為什么要這么做呢?筆者認為,異常的處理存在著一套哲學思想:對于一個應用系統來說,系統所發生的任何異常或者錯誤對操作用戶來說都是系統"運行時"異 常,都是這個應用系統內部的異常。這也是異常轉譯和應用系統異常框架設計的指導原則。在系統中大量處理非檢查異常的負面影響很多,最重要的一個方面就是代 碼可讀性降低,程序編寫復雜,異常處理的代碼也很蒼白無力。因此,很有必要將這些檢查異常Exception和錯誤Error轉換為 RuntimeException異常,讓程序員根據情況來決定是否捕獲和處理所發生的異常。
圖中的三條線標識轉換的方向,分三種情況:
①:Error到Exception:將錯誤轉換為異常,并繼續拋出。例如Spring WEB框架中,將org.springframework.web.servlet.DispatcherServlet的doDispatch()方法 中,將捕獲的錯誤轉譯為一個NestedServletException異常。這樣做的目的是為了最大限度挽回因錯誤發生帶來的負面影響。因為一個 Error常常是很嚴重的錯誤,可能會引起系統掛起。
②:Exception到RuntimeException:將檢查異常轉換為RuntimeException可以讓程序代碼變得更優雅,讓開發人員集中經理設計更合理的程序代碼,反過來也增加了系統發生異常的可能性。
③:Error到RuntimeException:目的還是一樣的。把所有的異常和錯誤轉譯為不檢查異常,這樣可以讓代碼更為簡潔,還有利于對錯誤和異常信息的統一處理。
1、 異常鏈
異常鏈顧名思義就是將異常發生的原因一個傳一個串起來,即把底層的異常信息傳給上層,這樣逐層拋出。Java API文檔中給出了一個簡單的模型:
try {
lowLevelOp();
} catch (LowLevelException le) {
throw (HighLevelException)
new HighLevelException().initCause(le);
}
當程序捕獲到了一個底層異常le,在處理部分選擇了繼續拋出一個更高級別的新異常給此方法的調用者。這樣異常的原因就會逐層傳遞。這樣,位于高層的異常遞 歸調用getCause()方法,就可以遍歷各層的異常原因。這就是Java異常鏈的原理。異常鏈的實際應用很少,發生異常時候逐層上拋不是個好注意,上 層拿到這些異常又能奈之何?而且異常逐層上拋會消耗大量資源,因為要保存一個完整的異常鏈信息。
五、 設計一個高效合理的異常處理框架
對于一個應用系統來說,發生所有異常在用戶看來都是應用系統內部的異常。因此應該設計一套應用系統的異常框架,以處理系統運行過程中的所有異常。
基于這種觀點,可以設計一個應用系統的異常比如叫做AppException。并且對用戶來說,這些異常都是運行應用系統運行時發生的,因此 AppException應該繼承RuntimeException,這樣系統中所有的其他異常都轉譯為AppException,當異常發生的時候,前 端接收到AppExcetpion并做統一的處理。畫出異常處理框架如圖 3 :
圖 3 一個應用系統的異常處理框架
在這個設計圖中,AppRuntimeException是系統異常的基類,對外只拋出這個異常,這個異常可以由前端(客戶端)接收處理,當異常發生時,客戶端的相關組件捕獲并處理這些異常,將"友好"的信息展示給客戶。
在AppRuntimeException下層,有各種各樣的異常和錯誤,最終都轉譯為 AppRuntimeException,AppRuntimeException下面還可以設計一些別的子類異常,比如 AppDAOException、OtherException等,這些都根據實際需要靈活處理。在往下就是如何將捕獲的原始異常比如 SQLException、HibernateException轉換為更高級一點AppDAOException。
有關異常框架設計這方面公認比較好的就是Spring,Spring中的所有異常都可以用 org.springframework.core.NestedRuntimeException來表示,并且該基類繼承的是 RuntimeException。Spring框架很龐大,因此設計了很多NestedRuntimeException的子類,還有異常轉換的工具, 這些都是非常優秀的設計思想。
六、 Java異常處理總結
回顧全文,總結一下Java異常處理的要點:
1、 異常是程序運行過程過程出現的錯誤,在Java中用類來描述,用對象來表示具體的異常。Java將其區分為Error與Exception,Error是程序無力處理的錯誤,Exception是程序可以處理的錯誤。異常處理是為了程序的健壯性。
2、 Java異常類來自于Java API定義和用戶擴展。通過繼承Java API異常類可以實現異常的轉譯。
3、 異常能處理就處理,不能處理就拋出,最終沒有處理的異常JVM會進行處理。
4、 異常可以傳播,也可以相互轉譯,但應該根據需要選擇合理的異常轉譯的方向。
5、 對于一個應用系統,設計一套良好的異常處理體系很重要。這一點在系統設計的時候就應該考慮到。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
