java的異常處理機制

2019-11-18 11:10:39

字體：大中小

來源：轉載

供稿：網友

　　關于 java 中引入的 Checked Exceptions，目前存在著很多反對意見。正方的觀點是引入 Checked Exceptions，可以增加程度的魯棒性。反方的觀點是 Checked Exceptions 很少被開發人員正確使用過，并且降低了程序開發的生產率和代碼的執行效率。

正方代表 James Gosling

http://www.artima.com/intv/solid.Html

反方代表 Anders Hejlsberg

http://www.artima.com/intv/csdes.html

中文版：http://www.csdn.net/develop/article/22/22612.shtm

我的一些觀點：

第一部分選擇checked or unchecked

這里需要對異常的理解。什么算異常？java的異常處理機制是用來干什么的？異常和錯誤有什么區別？

異常機制就是java的錯誤處理機制！java中的異常意味著2點：第一，讓錯誤處理代碼更有條理。這使得

正常代碼和錯誤處理代碼分離。第二，引入了context的概念，認為有些錯誤是可以被處理的。問題就出在這兒了。

java的checked異常指的就是在當前context不能被處理的錯誤！

這句話其實是對上面2點的總結。首先checked異常是一種錯誤，其次這種錯誤可以被處理（或修復）。

checked異常就是可以被處理（修復）的錯誤，unchecked異常其實就是無法處理（修復）的錯誤。

說到這兒，應該清楚了。別的語言沒有checked異常，就是說它們認為錯誤都無法被修復，至少在語言級

不提供錯誤修復的支持。java的catch clause干的就是錯誤修復的事。

我的理解是，用好java的異常，其實就是搞清楚什么時候該用checked異常。應該把unchecked異常當作

缺省行為。unchecked異常的意思是：當我做這件事時，不可思議的情況發生了，我沒辦法正常工作下去！

然后拋出一個unchecked異常，程序掛起。而checked異常的意思是：當我做這件事時，有意外情況發生，

可以肯定的是，活是沒法干了，但是要不要掛起程序，我這個函數沒法做主，我只能匯報上級！

其實，從上面的分析可以看出，java引入checked異常只是讓程序員多了一個選擇，它并不強迫你使用checked異常。

假如你對什么時候應該使用checked異常感到迷惑，那么最簡單的辦法就是，不要使用checked異常！這里包括2個

方面：

第一，你自己不必創建新的異常類，也不必在你的代碼中拋出checked異常，錯誤發生后只管拋出unchecked異常；

第二，對已有API的checked異常統統catch后轉為unchecked異常！

使用unchecked異常是最省事的辦法。用這種方法也可以享受“正常代碼和錯誤處理代碼分離”的好處。因為我們在調用方法時，

不用根據其返回值判定是否有錯誤出現，只管調用，只管做正事就ok了。假如出現錯誤，程序自然會知道并掛起。這樣的效果是怎樣

的呢？

第一，我們的業務代碼很清楚，基本都是在處理業務問題，而沒有一大堆判定是否有錯的冗余代碼。（想想看，假如沒有

throw異常的機制，你只能通過函數的返回值來判定錯誤，那么你在每個調用函數的地方都會有判定代碼！）

第二，我們的代碼假設一切正常，假如確實如此，那么它工作良好。但是一旦出現任何錯誤，程序就會掛起停止運行。當然，你可以查看

日志找到錯誤信息。

那么使用checked異常又是怎樣的呢？

第一，你需要考慮更多的問題。首先在設計上就會更加復雜，其次就是代碼更加冗長。設計上復雜

體現在以下方面：

1 對異常（錯誤）的抽象和理解。你得知道什么情況才能算checked異常，使得上級確實能夠處理（修復）這種異常，并且讓整個程序

從這種設計中確實得到好處。

2 對整個自定義checked異常繼續體系的設計。正如那篇文章所說，總不能在一個方法后面拋出20個異常吧！設計自定義checked異常，

就要考慮方法簽名問題，在合適的時候拋出合適的異常（不能一味的拋出最具體的異常，也不能一味拋出最抽象的異常）

第二，業務代碼相比較使用unchecked的情況而言，不夠直接了當了。引入了throws簽名和catch clause，代碼里有很多catch，方法

簽名也和異常綁定了。

第三，有了更強的錯誤處理能力。假如發生了checked異常，我們有能力處理（修復）它。表現在不是任何錯誤都會導致程序掛起，出現了

checked異常，程序可能照樣運行。整個程序更加健壯，而代價就是前面2條。

第二部分使用checked異常的最佳實踐

現在假設有些錯誤我們確定為checked異常，那么我們針對這些checked異常要怎樣編碼才合理呢？

1 不要用checked異常做流程控制。無論如何，checked異常也是一種錯誤。只是我們可以處理（修復）它而已。這種錯誤和普通業務

流程還是有區別的，而且從效率上來說，用異?？刂茦I務流程是不劃算的。其實這個問題有時候很難界定，因為checked異?！翱梢孕迯汀?，

那么就是說修復后程序照常運行，這樣一來真的輕易跟普通業務流程混淆不清。比如注冊用戶時用戶名已經存在的問題。這個時候我們要考慮，

為什么要用checked異常？這和使用業務流程相比，給我帶來了什么好處？（注重checked異?？梢孕迯?，這是和unchecked異常本質的區別）

照我的理解，checked異常應該是介于正常業務流程和unchecked異常（嚴重錯誤）之間的一種比較嚴重的錯誤。出現了這種錯誤，程序無法

完成正常的功能是肯定的了，但我們可以通過其他方式彌補（甚至修復），總之不會讓程序掛起就是。其實這一點也是設計checked異常時要考慮

的問題，也是代價之一吧。

2 對checked異常的封裝。這里面包括2個問題：

第一，假如要創建新的checked異常，盡量包含多一點信息，假如只是一條message，那么用Exception好了。當然，用Exception會

失去異常的型別信息，讓客戶端無法判定具體型別，從而無法針對特定異常進行處理。

第二，不要讓你要拋出的checked exception升級到較高的層次。例如，不要讓SQLException延伸到業務層。這樣可以避免方法

簽名后有太多的throws。在業務層將持久層的所有異常統統歸為業務層自定義的一種異常。

3 客戶端調用含有throws的方法要注重：

第一，不要忽略異常。既然是checked異常，catch clause里理應做些有用的事情——修復它！catch里為空白或者僅僅打印出錯信息都是

不妥的！為空白就是假裝不知道甚至瞞天過海，但是，出來混遲早要還的，遲早會報unchecked異常并程序掛起！非典就是個例子。

打印出錯信息也好不到哪里去，和空白相比除了多幾行信息沒啥區別。假如checked異常都被這么用，那真的不如當初都改成unchecked好了，

大家都省事！

第二，不要捕捉頂層的Exception。你這么干，就是在犯罪！因為unchecked異常也是一種Exception！你把所有異常都捕捉了——不是我

不相信你的能力，你根本就不知道該如何處理！這樣做的直接的后果就是，你的程序一般來說是不會掛起了，但是出現錯誤的時候功能廢了，

表面上卻看不出什么！當然，深究起來，這也不是什么罪大惡極，假如你在catch里打印了信息，這和上面那條的情況是差不多的。而這2條

的共同點就是，沒有正確使用checked異常！費了那么大勁設計的checked異常就是給你們上級（客戶端）用的，結果你們不會用！真的

不如用unchecked干脆利落了！

上一篇：JAR文件包及jar命令詳解

下一篇：動態圖文結合