范文為教學(xué)中作為模范的文章，也常常用來指寫作的模板,。常常用于文秘寫作的參考,，也可以作為演講材料編寫前的參考。那么我們該如何寫一篇較為完美的范文呢,？下面是小編為大家收集的優(yōu)秀范文,，供大家參考借鑒，希望可以幫助到有需要的朋友,。
j2ee的理解 j2ee平臺篇一
j2ee核心是一組技術(shù)規(guī)范與指南,，其中所包含的各類組件、服務(wù)架構(gòu)及技術(shù)層次,，均有共同的標準及規(guī)格,，讓各種依循j2ee架構(gòu)的不同平臺之間，存在良好的兼容性,。下面是小編整理的關(guān)于j2ee系統(tǒng)異常的處理準則,，歡迎大家參考!
異常的處理是每個java程序員時常面對的問題，但是很多人沒有原則,，遇到異常也不知道如何去處理,，于是遇到檢查異常就胡亂try...catch...一把，tacktrace()一下了事,，這種做法通常除了調(diào)試排錯有點作用外,，沒任何價值。對于運行時異常,，則干脆置之不理,。
原因是很多開發(fā)者缺乏對異常的認識和分析，首先應(yīng)該明白java異常體系結(jié)構(gòu),，一種分層繼承的關(guān)系,，你必須對層次結(jié)構(gòu)熟爛于心：
throwable(必須檢查)
error(非必須檢查)
exception(必須檢查)
runtimeexception(非必須檢查)
一般把exception異常及其直接子類(除了runtimeexception之外)的異常稱之為檢查異常。把runtimeexception以及其子類的異常稱之為非檢查異常,，也叫運行時異常,。
對于throwable和error，則用的很少,，一般會用在一些基礎(chǔ)框架中,，這里不做討論。
下面針對j2ee的分層架構(gòu)：dao層,、業(yè)務(wù)層,、控制層,、展示層的異常處理做個分析，并給出一般處理準則,。
如果你用了spring的dao模板來實現(xiàn),，則dao層沒有檢查異常拋出，代碼非常的優(yōu)雅,。但是,，如果你的dao采用了原始的jdbc來寫，這時候,，你不能不對異常做處理了,，因為難以避免的sqlexception會如影隨形的`跟著你。對已這種dao級別的異常,，異常了你又能如何呢?與其這樣胡亂try...catch...,，囫圇吞棗消滅了異常不如讓異常以另外一種非檢查的方式向外傳遞,。這樣做好處有二：
1),、dao的接口不被異常所污染，假設(shè)你拋出了sqlexception,，以后要是換了spring dao模板,，那dao接口就不再拋出了sqlexception，這樣,，你的接口拋出異常就是對接口的污染,。
2)、dao異常向外傳播給更高層處理,，以便異常的錯誤原因不丟失,，便于排查錯誤或進行捕獲處理。
這里還有一個設(shè)計上常常令人困擾的問題：很多人會問,，那定義一個什么樣的異常拋出呢,，或者是直接拋出一個throw runtimeexception(e)? 對于這個問題，需要分場合,，如果系統(tǒng)小,，你可以直接拋出一個throw runtimeexception(e)，但對于一個龐大的多模塊系統(tǒng)來說,，不要拋這種原生的非檢查異常,，而要拋出自定義的非檢查異常，這樣不但利于排錯,，而且有利于系統(tǒng)異常的處理,，通常針對每一個模塊，粗粒度的定義一個運行時dao異常,。比如：throw new modelxxxdaoruntimeexception(".....",e),，對于msg信息,，你可寫也可不寫，根據(jù)需要靈活拋出,。
這里常見一個很愚昧的處理方式,，為每個dao定義一個異常，呵呵,，這樣累不累啊,，有多大意義，在service層中調(diào)用時候,，如果要捕獲,，還要捕獲出一堆異常。這樣致命的問題是代碼混亂,，維護困難,，閱讀也困難，dao的異常應(yīng)該是粗粒度的,。
習(xí)慣上把業(yè)務(wù)層稱之為service層或者服務(wù)層,，service層的代表的是業(yè)務(wù)邏輯，不要迷信分太多太多層有多大好處,，除非需要,，否則別盲目劃分不必要的層，層越多,，效率越差,，根據(jù)需要夠用就行了。
service接口中的每個方法代表一個特定的業(yè)務(wù),，而這個業(yè)務(wù)一定是一個完整的業(yè)務(wù),，通常會看到一些傻x的做法，數(shù)據(jù)庫事務(wù)配置在service層,，而service的實現(xiàn)就是dao的直接調(diào)用,，然后在控制層(action)中，調(diào)用了好多service去完成一個業(yè)務(wù),，你氣得已經(jīng)無語了,，低頭找磚頭去!!!
搞明白以上兩個問題后再回過頭看異常怎么處理，service層通常依賴dao,，而service層的通常也會因為調(diào)用別的非檢查異常方法而必須面對異常處理的問題,，這里和dao層又有所不同，彼一時,，此一時嘛!
一般來說一個小模塊對應(yīng)一個service,，當然也許有兩個或多個，針對這個模塊的service定義一個非檢查異常,，以應(yīng)付那些不可避免的異常檢查,，這個自定義異?？梢院唵蔚拿麨閤xxserviceruntimeexception，將捕獲到的異常順勢轉(zhuǎn)譯為非檢查異常后拋出,。我喜歡這么做,，因為前臺是j2ee應(yīng)用，前臺是web頁面,，它們的struts2等框架會自動捕獲所有service層的異常,，并把異常交給開發(fā)者去自由處理。
但是還有一種情況,，由于一些特殊的限制,，如果某個異常一旦發(fā)生，必須做什么什么處理,，而這種處理時硬性要求,，或者調(diào)用某個service方法，必須檢查處理什么異常,，也可以拋出非檢查的自定義異常,，往往出現(xiàn)這種情況的是政治原因。不推崇這種做法,，但也不排斥,。
總之，對于接口,，盡可能不去用異常污染她!
控制層說的簡單些就是常見的action層，主要是控制頁面請求的處理,?？刂茖油ǔ６家蕾囉趕ervice層，現(xiàn)在比較流行的框架對控制層做得都相當?shù)牡轿?，比如struts2,、springmvc等等，他們的控制層框架會捕獲業(yè)務(wù)層的所有異常,，并在控制層中聲明可能拋出exception,，因此控制層一般不處理什么異常。
如果是控制層中因為調(diào)用了一些非檢查異常的方法,，比如io操作等,，可以簡單處理下異常，保證流的安全,，這才是目的,。
對于頁面異常，處理的方式多種多樣,，一是不處理異常,，一旦異常了,，頁面就報錯。二是定義出錯頁面,，根據(jù)異常的類型以及所在的模塊,，導(dǎo)航到出錯頁面。
一般來說,，出錯頁面是更友好的做法,。
另外還有特殊的處理方式，展示頁面的模板可以捕獲異常,，并根據(jù)情況將異常信息鋪到相應(yīng)的位置,，這樣就更友好了，不過復(fù)雜度較高,。
怎么處理,，就看需要了,。
五,、總結(jié)
1)、對于異常處理,，應(yīng)該從設(shè)計,、需要、維護等多個角度綜合考慮,，有一個通用準則：千萬別捕獲了異常什么事情都不干,，這樣一旦出現(xiàn)異常了，你沒法依據(jù)異常信息來排錯,。
2)、對于j2ee多層架構(gòu)系統(tǒng)來說,，盡可能避免(因拋出異常帶來的)接口污染,。
s("content_relate");【關(guān)于j2ee系統(tǒng)異常的處理準則】相關(guān)文章：
1.
j2ee系統(tǒng)優(yōu)化：對象與循環(huán)
2.關(guān)于系統(tǒng)不認硬盤的常規(guī)處理方法
3.系統(tǒng)不認硬盤的常規(guī)處理方法
4.j2ee項目中的異常處理
5.j2ee架構(gòu)環(huán)境監(jiān)控系統(tǒng)設(shè)計
6.j2ee系統(tǒng)優(yōu)化之對象與循環(huán)簡介
7.j2ee的簡介
8.j2ee簡介
