J2EE項目異常處理
爲什麼要在J2EE項目中談異常處理呢?可能許多java初學者都想說:“異常處理不就是try….catch…finally嗎?這誰都會啊!”。筆者在初學java時也是這樣認爲的。如何在一個多層的j2ee項目中定義相應的異常類?在項目中的每一層如何進行異常處理?異常何時被拋出?異常何時被記錄?異常該怎麼記錄?何時需要把checked Exception轉化成unchecked Exception ,何時需要把unChecked Exception轉化成checked Exception?異常是否應該呈現到前端頁面?如何設計一個異常框架?本文將就這些問題進行探討。
1. JAVA異常處理
在面向過程式的編程語言中,我們可以通過返回值來確定方法是否正常執行。比如在一個c語言編寫的程序中,如果方法正確的執行則返回1.錯誤則返回0。在vb或delphi開發的應用程序中,出現錯誤時,我們就彈出一個消息框給用戶。
通過方法的返回值我們並不能獲得錯誤的詳細信息。可能因爲方法由不同的程序員編寫,當同一類錯誤在不同的方法出現時,返回的結果和錯誤信息並不一致。
所以java語言採取了一個統一的異常處理機制。
什麼是異常?運行時發生的可被捕獲和處理的錯誤。
在java語言中,Exception是所有異常的父類。任何異常都擴展於Exception類。Exception就相當於一個錯誤類型。如果要定義一個新的錯誤類型就擴展一個新的Exception子類。採用異常的好處還在於可以精確的定位到導致程序出錯的源代碼位置,並獲得詳細的錯誤信息。
Java異常處理通過五個關鍵字來實現,try,catch,throw ,throws, finally。具體的異常處理結構由try….catch….finally塊來實現。try塊存放可能出現異常的java語句,catch用來捕獲發生的異常,並對異常進行處理。Finally塊用來清除程序中未釋放的資源。不管理try塊的代碼如何返回,finally塊都總是被執行。
一個典型的異常處理代碼
java 代碼
- public String getPassword(String userId)throws DataAccessException{
- String sql = “select password from userinfo where userid=’”+userId +”’”;
- String password = null;
- Connection con = null;
- Statement s = null;
- ResultSet rs = null;
- try{
- con = getConnection();//獲得數據連接
- s = con.createStatement();
- rs = s.executeQuery(sql);
- while(rs.next()){
- password = rs.getString(1);
- }
- rs.close();
- s.close();
- }
- Catch(SqlException ex){
- throw new DataAccessException(ex);
- }
- finally{
- try{
- if(con != null){
- con.close();
- }
- }
- Catch(SQLException sqlEx){
- throw new DataAccessException(“關閉連接失敗!”,sqlEx);
- }
- }
- return password;
- }
可以看出Java的異常處理機制具有的優勢:
給錯誤進行了統一的分類,通過擴展Exception類或其子類來實現。從而避免了相同的錯誤可能在不同的方法中具有不同的錯誤信息。在不同的方法中出現相同的錯誤時,只需要throw 相同的異常對象即可。
獲得更爲詳細的錯誤信息。通過異常類,可以給異常更爲詳細,對用戶更爲有用的錯誤信息。以便於用戶進行跟蹤和調試程序。
把正確的返回結果與錯誤信息分離。降低了程序的複雜度。調用者無需要對返回結果進行更多的瞭解。
強制調用者進行異常處理,提高程序的質量。當一個方法聲明需要拋出一個異常時,那麼調用者必須使用try….catch塊對異常進行處理。當然調用者也可以讓異常繼續往上一層拋出。
2. Checked 異常 還是 unChecked 異常?
Java異常分爲兩大類:checked 異常和unChecked 異常。所有繼承java.lang.Exception 的異常都屬於checked異常。所有繼承java.lang.RuntimeException的異常都屬於unChecked異常。
當一個方法去調用一個可能拋出checked異常的方法,必須通過try…catch塊對異常進行捕獲進行處理或者重新拋出。
我們看看Connection接口的createStatement()方法的聲明。
public Statement createStatement() throws SQLException;
SQLException是checked異常。當調用createStatement方法時,java強制調用者必須對SQLException進行捕獲處理。
java 代碼
- public String getPassword(String userId){
- try{
- ……
- Statement s = con.createStatement();
- ……
- Catch(SQLException sqlEx){
- ……
- }
- ……
- }
java 代碼
- public String getPassword(String userId)throws SQLException{
- Statement s = con.createStatement();
- }
(當然,像Connection,Satement這些資源是需要及時關閉的,這裏僅是爲了說明checked 異常必須強制調用者進行捕獲或繼續拋出)
unChecked異常也稱爲運行時異常,通常RuntimeException都表示用戶無法恢復的異常,如無法獲得數據庫連接,不能打開文件等。雖然用戶也可以像處理checked異常一樣捕獲unChecked異常。但是如果調用者並沒有去捕獲unChecked異常時,編譯器並不會強制你那麼做。
比如一個把字符轉換爲整型數值的代碼如下:
java 代碼
- String str = “123”;
- int value = Integer.parseInt(str);
parseInt的方法簽名爲:
java 代碼
- public static int parseInt(String s) throws NumberFormatException
當傳入的參數不能轉換成相應的整數時,將會拋出NumberFormatException。因爲NumberFormatException擴展於RuntimeException,是unChecked異常。所以調用parseInt方法時無需要try…catch
因爲java不強制調用者對unChecked異常進行捕獲或往上拋出。所以程序員總是喜歡拋出unChecked異常。或者當需要一個新的異常類時,總是習慣的從RuntimeException擴展。當你去調用它些方法時,如果沒有相應的catch塊,編譯器也總是讓你通過,同時你也根本無需要去了解這個方法倒底會拋出什麼異常。看起來這似乎倒是一個很好的辦法,但是這樣做卻是遠離了java異常處理的真實意圖。並且對調用你這個類的程序員帶來誤導,因爲調用者根本不知道需要在什麼情況下處理異常。而checked異常可以明確的告訴調用者,調用這個類需要處理什麼異常。如果調用者不去處理,編譯器都會提示並且是無法編譯通過的。當然怎麼處理是由調用者自己去決定的。
所以Java推薦人們在應用代碼中應該使用checked異常。就像我們在上節提到運用異常的好外在於可以強制調用者必須對將會產生的異常進行處理。包括在《java Tutorial》等java官方文檔中都把checked異常作爲標準用法。
使用checked異常,應意味着有許多的try…catch在你的代碼中。當在編寫和處理越來越多的try…catch塊之後,許多人終於開始懷疑checked異常倒底是否應該作爲標準用法了。
甚至連大名鼎鼎的《thinking in java》的作者Bruce Eckel也改變了他曾經的想法。Bruce Eckel甚至主張把unChecked異常作爲標準用法。並發表文章,以試驗checked異常是否應該從java中去掉。Bruce Eckel語:“當少量代碼時,checked異常無疑是十分優雅的構思,並有助於避免了許多潛在的錯誤。但是經驗表明,對大量代碼來說結果正好相反”
關於checked異常和unChecked異常的詳細討論可以參考
Alan Griffiths http://www.octopull.demon.co.uk/java/ExceptionalJava.html
使用checked異常會帶來許多的問題。
checked異常導致了太多的try…catch 代碼
可能有很多checked異常對開發人員來說是無法合理地進行處理的,比如SQLException。而開發人員卻不得不去進行try…catch。當開發人員對一個checked異常無法正確的處理時,通常是簡單的把異常打印出來或者是乾脆什麼也不幹。特別是對於新手來說,過多的checked異常讓他感到無所適從。
java 代碼
- try{
- ……
- Statement s = con.createStatement();
- ……
- Catch(SQLException sqlEx){
- sqlEx.PrintStackTrace();
- }
- 或者
- try{
- ……
- Statement s = con.createStatement();
- ……
- Catch(SQLException sqlEx){
- //什麼也不幹
- }
checked異常導致了許多難以理解的代碼產生
當開發人員必須去捕獲一個自己無法正確處理的checked異常,通常的是重新封裝成一個新的異常後再拋出。這樣做並沒有爲程序帶來任何好處。反而使代碼晚難以理解。
就像我們使用JDBC代碼那樣,需要處理非常多的try…catch.,真正有用的代碼被包含在try…catch之內。使得理解這個方法變理困難起來
checked異常導致異常被不斷的封裝成另一個類異常後再拋出
java 代碼
- public void methodA()throws ExceptionA{
- …..
- throw new ExceptionA();
- }
- public void methodB()throws ExceptionB{
- try{
- methodA();
- ……
- }catch(ExceptionA ex){
- throw new ExceptionB(ex);
- }
- }
- Public void methodC()throws ExceptinC{
- try{
- methodB();
- …
- }
- catch(ExceptionB ex){
- throw new ExceptionC(ex);
- }
- }
checked異常導致破壞接口方法
一個接口上的一個方法已被多個類使用,當爲這個方法額外添加一個checked異常時,那麼所有調用此方法的代碼都需要修改。
可見上面這些問題都是因爲調用者無法正確的處理checked異常時而被迫去捕獲和處理,被迫封裝後再重新拋出。這樣十分不方便,並不能帶來任何好處。在這種情況下通常使用unChecked異常。
chekced異常並不是無一是處,checked異常比傳統編程的錯誤返回值要好用得多。通過編譯器來確保正確的處理異常比通過返回值判斷要好得多。
如果一個異常是致命的,不可恢復的。或者調用者去捕獲它沒有任何益處,使用unChecked異常。
如果一個異常是可以恢復的,可以被調用者正確處理的,使用checked異常。
在使用unChecked異常時,必須在在方法聲明中詳細的說明該方法可能會拋出的unChekced異常。由調用者自己去決定是否捕獲unChecked異常
倒底什麼時候使用checked異常,什麼時候使用unChecked異常?並沒有一個絕對的標準。但是筆者可以給出一些建議
當所有調用者必須處理這個異常,可以讓調用者進行重試操作;或者該異常相當於該方法的第二個返回值。使用checked異常。
這個異常僅是少數比較高級的調用者才能處理,一般的調用者不能正確的處理。使用unchecked異常。有能力處理的調用者可以進行高級處理,一般調用者乾脆就不處理。
這個異常是一個非常嚴重的錯誤,如數據庫連接錯誤,文件無法打開等。或者這些異常是與外部環境相關的。不是重試可以解決的。使用unchecked異常。因爲這種異常一旦出現,調用者根本無法處理。
如果不能確定時,使用unchecked異常。並詳細描述可能會拋出的異常,以讓調用者決定是否進行處理。
。。。http://www.iteye.com/topic/72170