http://blog.csdn.net/junlixxu/article/details/6096266
一、 異常的概念和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{ //（嘗試運行的）程序代碼 }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");
- }
public static void test3() throws Exception{ //拋出一個檢查異常 throw new Exception("方法test3中的Exception"); }
4、 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);
- }
public class DAOException extends RuntimeException { //(省略了部分代碼) public DAOException(String message, Throwable cause) { super(message, cause); } }
比如有一個SQLException類型的異常對象e，要轉換爲DAOException，可以這麼寫：
- DAOException daoEx = new DAOException ( "SQL異常", e);
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);
- }
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、 對於一個應用系統，設計一套良好的異常處理體系很重要。這一點在系統設計的時候就應該考慮到。