避免在Java中使用Checked Exception(轉)
避免在Java中使用Checked Exception(轉)[@more@]這篇文章指出了Java中checked Exception的一些缺點,提出應該在程式設計中避免使用checked Exception,對於需要處理checked Exception的程式碼,可以使用ExceptionAdapter這個類對checked Exception進行包裝。這篇文章的概念和ExceptionAdapter這個類均源自Bruce Eckel的Does Java need Checked Exception。
Java的Exception分為兩類,一類是RuntimeException及其子類,另外一類就是checked Exception。Java要求函式對沒有被catch處理掉的checked Exception,需要將其寫在函式的宣告部分。然而,這一要求常常給程式設計師帶來一些不必要的負擔。
為了避免在函式宣告中寫throws部分,在Java專案裡面常常可以看到以下程式碼用來‘吞掉’Exception:
try {
// ...
} catch (Exception ex) {
ex.printStackTrace();
}
這顯然不是一個好的處理Exception辦法,事實上,catch並處理一個Exception意味著讓程式從發生的錯誤(Exception)中恢復過來。從這種意義上說,已上的程式碼只可能在一些很簡單的情況下工作而不帶來問題。
對於很多Exception,往往沒有去處理它並讓程式從錯誤中恢復出來的辦法,這時唯一能做的事情可能就是在介面上顯示一些提示資訊給使用者。這種情況下讓程式丟擲遇到的Exception是更為合理的做法。然而,這樣做會使得一些函式的宣告急劇膨脹。一個函式可能需要宣告會丟擲的7、8個 checked Exception,而且每個呼叫它的函式也需要同樣的宣告。
比這更糟糕的是,這有可能破壞類設計的open-close原則。簡單來說,open-close原則是指當擴充套件一個模組的時候,可以不影響其現有的client。open-close原則是透過繼承來實現的,當繼承一個類的時候,我們既擴充套件了這個類,也不會影響原有的client(因為對這個類沒有改動)。
現在考慮下面這種情況,有一個父類Base:
public class Base {
public void foo() throws ExceptionA {
// ...
}
}
現在需要繼承Base這個類並過載foo這個方法,在新的實現中,foo可能丟擲ExceptionB:
public class Extend extends Base {
public void foo() throws ExceptionB {
// ...
}
}
然而,這樣寫在Java裡面是不合法的,因為Java把可能會丟擲的Exception看作函式特徵的一部分,子類宣告丟擲的Exception必須是父類的子集。
可以在Base類的foo方法中加入丟擲ExceptionB的宣告,然而,這樣就破壞了open-close原則。而且,有時我們沒有辦法去修改父類,比如當過載一個Jdk裡的類的時候。
另一個可能的做法是在Extend的foo方法中catch住ExceptionB,然後構造一個ExceptionA並丟擲。這是個可行的辦法但也只是一個權宜之計。
如果使用RuntimeException,這些問題都不會存在。這說明checked Exception並不是一個很實用的概念,也意味著在程式設計的時候,我們應該讓自己的Exception類繼承RuntimeException而不是Exception。(這和JDK的建議正好相反,但實踐證明這樣做程式碼的質量更好。)
對於那些需要處理checked Exception的程式碼,可以利用一個ExceptionAdapter的類把checked Exception包裝成一個RuntimeException丟擲。ExceptionAdapter來自Bruce Eckel的Does Java need Checked Exception這篇文章,在這裡的ExceptionAdapter是我根據JDK 1.4修改過的:
public class ExceptionAdapter extends RuntimeException {
public ExceptionAdapter(Exception ex) {
super(ex);
}
public void printStackTrace(java.io.PrintStream s) {
getCause().printStackTrace(s);
}
public void printStackTrace(java.io.PrintWriter s) {
getCause().printStackTrace(s);
}
// rethrow()的作用是把被包裝的Exception再次丟擲。
public void rethrow()
throws Exception
{
throw (Exception) getCause();
}
}
Java的Exception分為兩類,一類是RuntimeException及其子類,另外一類就是checked Exception。Java要求函式對沒有被catch處理掉的checked Exception,需要將其寫在函式的宣告部分。然而,這一要求常常給程式設計師帶來一些不必要的負擔。
為了避免在函式宣告中寫throws部分,在Java專案裡面常常可以看到以下程式碼用來‘吞掉’Exception:
try {
// ...
} catch (Exception ex) {
ex.printStackTrace();
}
這顯然不是一個好的處理Exception辦法,事實上,catch並處理一個Exception意味著讓程式從發生的錯誤(Exception)中恢復過來。從這種意義上說,已上的程式碼只可能在一些很簡單的情況下工作而不帶來問題。
對於很多Exception,往往沒有去處理它並讓程式從錯誤中恢復出來的辦法,這時唯一能做的事情可能就是在介面上顯示一些提示資訊給使用者。這種情況下讓程式丟擲遇到的Exception是更為合理的做法。然而,這樣做會使得一些函式的宣告急劇膨脹。一個函式可能需要宣告會丟擲的7、8個 checked Exception,而且每個呼叫它的函式也需要同樣的宣告。
比這更糟糕的是,這有可能破壞類設計的open-close原則。簡單來說,open-close原則是指當擴充套件一個模組的時候,可以不影響其現有的client。open-close原則是透過繼承來實現的,當繼承一個類的時候,我們既擴充套件了這個類,也不會影響原有的client(因為對這個類沒有改動)。
現在考慮下面這種情況,有一個父類Base:
public class Base {
public void foo() throws ExceptionA {
// ...
}
}
現在需要繼承Base這個類並過載foo這個方法,在新的實現中,foo可能丟擲ExceptionB:
public class Extend extends Base {
public void foo() throws ExceptionB {
// ...
}
}
然而,這樣寫在Java裡面是不合法的,因為Java把可能會丟擲的Exception看作函式特徵的一部分,子類宣告丟擲的Exception必須是父類的子集。
可以在Base類的foo方法中加入丟擲ExceptionB的宣告,然而,這樣就破壞了open-close原則。而且,有時我們沒有辦法去修改父類,比如當過載一個Jdk裡的類的時候。
另一個可能的做法是在Extend的foo方法中catch住ExceptionB,然後構造一個ExceptionA並丟擲。這是個可行的辦法但也只是一個權宜之計。
如果使用RuntimeException,這些問題都不會存在。這說明checked Exception並不是一個很實用的概念,也意味著在程式設計的時候,我們應該讓自己的Exception類繼承RuntimeException而不是Exception。(這和JDK的建議正好相反,但實踐證明這樣做程式碼的質量更好。)
對於那些需要處理checked Exception的程式碼,可以利用一個ExceptionAdapter的類把checked Exception包裝成一個RuntimeException丟擲。ExceptionAdapter來自Bruce Eckel的Does Java need Checked Exception這篇文章,在這裡的ExceptionAdapter是我根據JDK 1.4修改過的:
public class ExceptionAdapter extends RuntimeException {
public ExceptionAdapter(Exception ex) {
super(ex);
}
public void printStackTrace(java.io.PrintStream s) {
getCause().printStackTrace(s);
}
public void printStackTrace(java.io.PrintWriter s) {
getCause().printStackTrace(s);
}
// rethrow()的作用是把被包裝的Exception再次丟擲。
public void rethrow()
throws Exception
{
throw (Exception) getCause();
}
}
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617731/viewspace-958174/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Java之Undeclared Checked ExceptionJavaException
- 這樣也行,在lambda表示式中優雅的處理checked exceptionException
- Java中Error和Exception的異同以及執行時異常(Runtime exception)與檢查型異常(checked exception)的區別JavaErrorException
- 淺談Kotlin的Checked Exception機制KotlinException
- 在 Java 8 中避免 Null 檢查JavaNull
- 淺談java異常[Exception] (轉)JavaException
- [轉載] java避免空指標異常_第1部分:在現代Java應用程式中避免空指標異常Java指標
- 避免在Java 介面中使用陣列的3 個理由Java陣列
- 避免在Java介面中使用陣列的3個理由Java陣列
- Java——ExceptionJavaException
- Java 中的Exception 有什麼用?JavaException
- [譯]iOS開發者在Swift中應避免過度使用@objciOSSwiftOBJ
- java中避免集合死鏈呼叫Java
- 在 Java 中如何使用 transientJava
- REST 在 Java 中的使用RESTJava
- Java checked異常和unchecked異常。Java
- 如何避免在Flask中使用Response物件Flask物件
- Java中的常量:如何避免反模式Java模式
- sqlserver在JAVA中的應用 (轉)SQLServerJava
- JWT登入鑑權:避免在使用者操作的過程中JWT到期跳轉登入JWT
- jQuery :checkedjQuery
- checked屬性值是true還是checked
- 亞馬遜認為在分散式系統中必須避免使用回退亞馬遜分散式
- 淺談 Java 中 this 的使用(轉)Java
- Java中如何避免空指標異常Java指標
- 在Java中this關鍵字的使用Java
- java exception and finally returnJavaException
- Java EE在SOA世界中的消亡?(轉)Java
- 在xmlspy中使用java的xslt轉換 (轉)XMLJava
- fmdb中databasequeue的使用,避免死鎖Database
- 【Java】【轉】在命令列中編譯和執行javaJava命令列編譯
- 在JAVA中使用正規表示式 (轉)Java
- 再談在Java中使用列舉(轉)Java
- 在ASP中使用簡單Java類 (轉)Java
- JAVA基礎:再談在Java中使用列舉(轉)Java
- DDK中"checked build"和"free build" 之區別UI
- Exception in thread "main" java.lang.NoClassDefFoundError錯誤資訊(轉帖)ExceptionthreadAIJavaError
- 在Java中,你真的會日期轉換嗎Java