Java之Checked Exception和Unchecked Exception使用的我的理解

**摘要：**最近一我的在搭程序後臺框架，碰到了一個問題，就是Exception類型的使用。因而我有了如下的一些想法。

1、 爲何須要使用異常

我的理解：在面向對象程序的開發過程當中，咱們須要對函數的輸入輸出檢測。當被調用者執行過程當中出錯的時候，在不改變大量改變現有程序結構的時候，在並沒有的簡單有效辦法辦法通知調用者調用異常，因此這時候異常出現了。
注意：
在linux開發中：調用出錯，一般返回-1或者NULL，而且系統調用設置線程局部變量errno!=0，表示調用錯誤，而後咱們可使用strerror(errno)輸出錯誤碼。 這樣每次函數調用咱們都須要檢測返回值，改變了咱們編寫代碼的結構，很是麻煩。
下面就是幾年前我爲了簡化linux函數調用寫的一個宏，在linux內核內部有相似實現，你們能夠去看下。

2、Java異常繼承體系結構

下圖簡單介紹了一下Java的異常繼承體系結構

3、異常的分類及其做用

1. CheckedException： （非RuntimeException及其子類以外的全部Exception）
   用於提醒開發人員調用API時候對異常處理，而且程序這次調用須要從異常中恢復。一旦運行時這些異常被拋出，表明程序編寫一定有BUG。
2. UnCheckedException：（RuntimeException及其子類）
   用於提醒開發人員調用API時候對異常處理，可是程序這次調用能夠沒必要恢復。
3. Error及其子類：
   程序徹底沒必要恢復，甚至沒必要捕捉，只須要在系統crash時，可以即時通知運維以及開發人員進行系統恢復，以及運行時軟硬件環境排查進行。

4、開發時候使用什麼樣的Exception

1. 只使用CheckedException
   優勢：
   強迫程序員對異常進行處理 ，代碼更加安全 缺點：
   a、函數聲明throws列表過長，開發人員可能偷工減料，針對於須要多個catch塊處理的，會被放入同一個catch塊處理
   b、底層API拋出一個異常，函數可能會須要對多個地方進行改寫
2. 只使用Unchecked Exception
   優勢：
   代碼更加簡潔，改動異常拋出時，不須要改動函數接口
   缺點：
   開發人員可能偷工減料，一個異常都不處理，統一交給全局異常處理模塊來進行
3. 二者混合使用 （JDK所採用的） 是上面兩種的折中方案，也是最優方案，對於Checked以及Unchecked異常區分的好，開發事半功倍，可是區分的很差，致使開發過程混亂。

5、CheckedException與UncheckedException的區分

這幾天思考了一下，關於如何區分，提煉爲如下幾句話：

1. 被調用者能夠恢復調用錯誤，不使用Exception，好比某些狀況下傳入null做爲參數（按常理須要拋出一個CheckedException而且由調用者顯示處理）
2. 被調用沒法處理的調用錯誤，可是調用者須要處理的程序錯誤，使用CheckedException，好比IOException，所打開文件不存在，那麼調用文件打開API接口的函數必需要對此處理
3. 被調用者與調用者都沒法處理的狀況，使用UncheckedException，好比ClassNotFoundException，咱們動態加載一個類，結果類的class文件不存在於classpath內，這種就直接讓全局異常處理模塊捕獲該異常而且輸出到日誌中便可

6、總結

雖然異常區分的原則十分簡單，可是每一個人對於程序錯誤是否是能夠處理的，若是處理的話，須要由哪些部分來進行處理的理解不盡相同。雖然素質較高的開發人員，對於異常區分的理解可能會趨於相同，可是高素質的永遠是少部分。
因此，在爲了保證項目質量的狀況下，總結起來就是在開發中儘可能只用一種異常，這樣避免異常混用，形成程序異常處理體系的混亂不堪。