如何在一個多層的J2EE專案中定義相應的異常類?在專案中的每一層如何進行異常處理?異常何時被丟擲?異常何時被記錄?異常該怎麼記錄?何時需要把checked Exception轉化成unchecked Exception ，何時需要把unChecked Exception轉化成checked Exception?異常是否應該呈現到前端頁面?如何設計一個異常框架?
異常的處理是每個Java程式設計師時常面對的問題，但是很多人沒有原則，遇到異常也不知道如何去處理，於是遇到檢查異常就胡亂h...一把，然後tStackTrace()一下了事，這種做法通常除了除錯排錯有點作用外，沒任何價值。對於執行時異常，則乾脆置之不理。
原因是很多開發者缺乏對異常的認識和分析，首先應該明白Java異常體系結構，一種分層繼承的關係，你必須對層次結構熟爛於心：
Throwable(必須檢查)
Error(非必須檢查)
Exception(必須檢查)
RuntimeException(非必須檢查)
一般把Exception異常及其直接子類(除了RuntimeException之外)的異常稱之為檢查異常。把RuntimeException以及其子類的異常稱之為非檢查異常，也叫執行時異常。
對於Throwable和Error，則用的很少，一般會用在一些基礎框架中，這裡不做討論。
下面針對J2EE的分層架構：DAO層、業務層、控制層、展示層的異常處理做個分析，並給出一般處理準則。
一、DAO層異常處理
如果你用了Spring的DAO模板來實現，則DAO層沒有檢查異常丟擲，程式碼非常的'優雅。但是，如果你的DAO採用了原始的JDBC來寫，這時候，你不能不對異常做處理了，因為難以避免的SQLException會如影隨形的跟著你。對已這種DAO級別的異常，異常了你又能如何呢?與其這樣胡亂h...，囫圇吞棗消滅了異常不如讓異常以另外一種非檢查的方式向外傳遞。這樣做好處有二：
1)、DAO的介面不被異常所汙染，假設你丟擲了SQLException，以後要是換了Spring DAO模板，那DAO介面就不再丟擲了SQLException，這樣，你的介面丟擲異常就是對介面的汙染。
2)、DAO異常向外傳播給更高層處理，以便異常的錯誤原因不丟失，便於排查錯誤或進行捕獲處理。
這裡還有一個設計上常常令人困擾的問題：很多人會問，那定義一個什麼樣的異常丟擲呢，或者是直接丟擲一個throw RuntimeException(e)? 對於這個問題，需要分場合，如果系統小，你可以直接丟擲一個throw RuntimeException(e)，但對於一個龐大的多模組系統來說，不要拋這種原生的非檢查異常，而要丟擲自定義的非檢查異常，這樣不但利於排錯，而且有利於系統異常的處理，通常針對每一個模組，粗粒度的定義一個執行時DAO異常。比如：throw new ModelXxxDAORuntimeException(".....",e)，對於msg資訊，你可寫也可不寫，根據需要靈活丟擲。
這裡常見一個很愚昧的處理方式，為每個DAO定義一個異常，呵呵，這樣累不累啊，有多大意義，在Service層中呼叫時候，如果要捕獲，還要捕獲出一堆異常。這樣致命的問題是程式碼混亂，維護困難，閱讀也困難，DAO的異常應該是粗粒度的。
二、業務層異常處理
習慣上把業務層稱之為Service層或者服務層，Service層的代表的是業務邏輯，不要迷信分太多太多層有多大好處，除非需要，否則別盲目劃分不必要的層，層越多，效率越差，根據需要夠用就行了。
Service介面中的每個方法代表一個特定的業務，而這個業務一定是一個完整的業務，通常會看到一些傻X的做法，資料庫事務配置在Service層，而Service的實現就是DAO的直接呼叫，然後在控制層(Action)中，呼叫了好多Service去完成一個業務，你氣得已經無語了，低頭找磚頭去!!!
搞明白以上兩個問題後再回過頭看異常怎麼處理，Service層通常依賴DAO，而Service層的通常也會因為呼叫別的非檢查異常方法而必須面對異常處理的問題，這裡和DAO層又有所不同，彼一時，此一時嘛!
一般來說一個小模組對應一個Service，當然也許有兩個或多個，針對這個模組的Service定義一個非檢查異常，以應付那些不可避免的異常檢查，這個自定義異常可以簡單的命名為XxxServiceRuntimeException，將捕獲到的異常順勢轉譯為非檢查異常後丟擲。我喜歡這麼做，因為前臺是J2EE應用，前臺是web頁面，它們的Struts2等框架會自動捕獲所有Service層的異常，並把異常交給開發者去自由處理。
但是還有一種情況，由於一些特殊的限制，如果某個異常一旦發生，必須做什麼什麼處理，而這種處理時硬性要求，或者呼叫某個Service方法，必須檢查處理什麼異常，也可以丟擲非檢查的自定義異常，往往出現這種情況的是政治原因。不推崇這種做法，但也不排斥。
總之，對於介面，儘可能不去用異常汙染她!
三、控制層異常
控制層說的簡單些就是常見的Action層，主要是控制頁面請求的處理。控制層通常都依賴於Service層，現在比較流行的框架對控制層做得都相當的到位，比如Struts2、SpringMVC等等，他們的控制層框架會捕獲業務層的所有異常，並在控制層中宣告可能丟擲Exception，因此控制層一般不處理什麼異常。
如果是控制層中因為呼叫了一些非檢查異常的方法，比如IO操作等，可以簡單處理下異常，保證流的安全，這才是目的。
四、顯示層異常處理
對於頁面異常，處理的方式多種多樣，一是不處理異常，一旦異常了，頁面就報錯。二是定義出錯頁面，根據異常的型別以及所在的模組，導航到出錯頁面。
一般來說，出錯頁面是更友好的做法。
另外還有特殊的處理方式，展示頁面的模板可以捕獲異常，並根據情況將異常資訊鋪到相應的位置，這樣就更友好了，不過複雜度較高。
怎麼處理，就看需要了。
五、總結
1)、對於異常處理，應該從設計、需要、維護等多個角度綜合考慮，有一個通用準則：千萬別捕獲了異常什麼事情都不幹，這樣一旦出現異常了，你沒法依據異常資訊來排錯。
2)、對於J2EE多層架構系統來說，儘可能避免(因丟擲異常帶來的)介面汙染。
