- 相關(guān)推薦
關(guān)于J2EE系統異常的處理準則
J2EE核心是一組技術(shù)規范與指南，其中所包含的各類(lèi)組件、服務(wù)架構及技術(shù)層次，均有共同的標準及規格，讓各種依循J2EE架構的不同平臺之間，存在良好的兼容性。下面是小編整理的關(guān)于J2EE系統異常的處理準則，歡迎大家參考!
J2EE系統異常的處理準則
異常的處理是每個(gè)Java程序員時(shí)常面對的問(wèn)題，但是很多人沒(méi)有原則，遇到異常也不知道如何去處理，于是遇到檢查異常就胡亂try...catch...一把，然后e.printStackTrace()一下了事，這種做法通常除了調試排錯有點(diǎn)作用外，沒(méi)任何價(jià)值。對于運行時(shí)異常，則干脆置之不理。
原因是很多開(kāi)發(fā)者缺乏對異常的認識和分析，首先應該明白Java異常體系結構，一種分層繼承的關(guān)系，你必須對層次結構熟爛于心：
Throwable(必須檢查)
Error(非必須檢查)
Exception(必須檢查)
RuntimeException(非必須檢查)
一般把Exception異常及其直接子類(lèi)(除了RuntimeException之外)的異常稱(chēng)之為檢查異常。把RuntimeException以及其子類(lèi)的異常稱(chēng)之為非檢查異常，也叫運行時(shí)異常。
對于Throwable和Error，則用的很少，一般會(huì )用在一些基礎框架中，這里不做討論。
下面針對J2EE的分層架構：DAO層、業(yè)務(wù)層、控制層、展示層的異常處理做個(gè)分析，并給出一般處理準則。
一、DAO層異常處理
如果你用了Spring的DAO模板來(lái)實(shí)現，則DAO層沒(méi)有檢查異常拋出，代碼非常的優(yōu)雅。但是，如果你的DAO采用了原始的JDBC來(lái)寫(xiě)，這時(shí)候，你不能不對異常做處理了，因為難以避免的SQLException會(huì )如影隨形的跟著(zhù)你。對已這種DAO級別的異常，異常了你又能如何呢?與其這樣胡亂try...catch...，囫圇吞棗消滅了異常不如讓異常以另外一種非檢查的方式向外傳遞。這樣做好處有二：
1)、DAO的接口不被異常所污染，假設你拋出了SQLException，以后要是換了Spring DAO模板，那DAO接口就不再拋出了SQLException，這樣，你的接口拋出異常就是對接口的污染。
2)、DAO異常向外傳播給更高層處理，以便異常的錯誤原因不丟失，便于排查錯誤或進(jìn)行捕獲處理。
這里還有一個(gè)設計上常常令人困擾的問(wèn)題：很多人會(huì )問(wèn)，那定義一個(gè)什么樣的異常拋出呢，或者是直接拋出一個(gè)throw RuntimeException(e)? 對于這個(gè)問(wèn)題，需要分場(chǎng)合，如果系統小，你可以直接拋出一個(gè)throw RuntimeException(e)，但對于一個(gè)龐大的多模塊系統來(lái)說(shuō)，不要拋這種原生的非檢查異常，而要拋出自定義的非檢查異常，這樣不但利于排錯，而且有利于系統異常的處理，通常針對每一個(gè)模塊，粗粒度的定義一個(gè)運行時(shí)DAO異常。比如：throw new ModelXxxDAORuntimeException(".....",e)，對于msg信息，你可寫(xiě)也可不寫(xiě)，根據需要靈活拋出。
這里常見(jiàn)一個(gè)很愚昧的處理方式，為每個(gè)DAO定義一個(gè)異常，呵呵，這樣累不累啊，有多大意義，在Service層中調用時(shí)候，如果要捕獲，還要捕獲出一堆異常。這樣致命的問(wèn)題是代碼混亂，維護困難，閱讀也困難，DAO的異常應該是粗粒度的。
二、業(yè)務(wù)層異常處理
習慣上把業(yè)務(wù)層稱(chēng)之為Service層或者服務(wù)層，Service層的代表的是業(yè)務(wù)邏輯，不要迷信分太多太多層有多大好處，除非需要，否則別盲目劃分不必要的層，層越多，效率越差，根據需要夠用就行了。
Service接口中的每個(gè)方法代表一個(gè)特定的業(yè)務(wù)，而這個(gè)業(yè)務(wù)一定是一個(gè)完整的業(yè)務(wù)，通常會(huì )看到一些傻X的做法，數據庫事務(wù)配置在Service層，而Service的實(shí)現就是DAO的直接調用，然后在控制層(Action)中，調用了好多Service去完成一個(gè)業(yè)務(wù)，你氣得已經(jīng)無(wú)語(yǔ)了，低頭找磚頭去!!!
搞明白以上兩個(gè)問(wèn)題后再回過(guò)頭看異常怎么處理，Service層通常依賴(lài)DAO，而Service層的通常也會(huì )因為調用別的非檢查異常方法而必須面對異常處理的問(wèn)題，這里和DAO層又有所不同，彼一時(shí)，此一時(shí)嘛!
一般來(lái)說(shuō)一個(gè)小模塊對應一個(gè)Service，當然也許有兩個(gè)或多個(gè)，針對這個(gè)模塊的Service定義一個(gè)非檢查異常，以應付那些不可避免的異常檢查，這個(gè)自定義異�？梢院�(jiǎn)單的命名為XxxServiceRuntimeException，將捕獲到的異常順勢轉譯為非檢查異常后拋出。我喜歡這么做，因為前臺是J2EE應用，前臺是web頁(yè)面，它們的Struts2等框架會(huì )自動(dòng)捕獲所有Service層的異常，并把異常交給開(kāi)發(fā)者去自由處理。
但是還有一種情況，由于一些特殊的限制，如果某個(gè)異常一旦發(fā)生，必須做什么什么處理，而這種處理時(shí)硬性要求，或者調用某個(gè)Service方法，必須檢查處理什么異常，也可以?huà)伋龇菣z查的自定義異常，往往出現這種情況的是政治原因。不推崇這種做法，但也不排斥。
總之，對于接口，盡可能不去用異常污染她!
三、控制層異常
控制層說(shuō)的簡(jiǎn)單些就是常見(jiàn)的Action層，主要是控制頁(yè)面請求的處理�？刂茖油ǔ６家蕾�(lài)于Service層，現在比較流行的框架對控制層做得都相當的到位，比如Struts2、SpringMVC等等，他們的控制層框架會(huì )捕獲業(yè)務(wù)層的所有異常，并在控制層中聲明可能拋出Exception，因此控制層一般不處理什么異常。
如果是控制層中因為調用了一些非檢查異常的方法，比如IO操作等，可以簡(jiǎn)單處理下異常，保證流的安全，這才是目的。
四、顯示層異常處理
對于頁(yè)面異常，處理的方式多種多樣，一是不處理異常，一旦異常了，頁(yè)面就報錯。二是定義出錯頁(yè)面，根據異常的類(lèi)型以及所在的模塊，導航到出錯頁(yè)面。
一般來(lái)說(shuō)，出錯頁(yè)面是更友好的做法。
另外還有特殊的處理方式，展示頁(yè)面的模板可以捕獲異常，并根據情況將異常信息鋪到相應的位置，這樣就更友好了，不過(guò)復雜度較高。
怎么處理，就看需要了。
五、總結
1)、對于異常處理，應該從設計、需要、維護等多個(gè)角度綜合考慮，有一個(gè)通用準則：千萬(wàn)別捕獲了異常什么事情都不干，這樣一旦出現異常了，你沒(méi)法依據異常信息來(lái)排錯。
2)、對于J2EE多層架構系統來(lái)說(shuō)，盡可能避免(因拋出異常帶來(lái)的)接口污染。
【J2EE系統異常的處理準則】相關(guān)文章：
J2EE項目中的異常處理01-22
Web服務(wù)中的異常處理09-17
javascript編程異常處理的方法08-04
Word頁(yè)面顯示異常處理辦法06-18
系統不認硬盤(pán)的常規處理方法03-04
什么是J2EE07-05
j2ee介紹07-22
J2EE的概念08-23