[[409061]]

 “二哥，今天就要學習異常了嗎?”三妹問。

“是的。只有正確地處理好異常，才能保證程序的可靠性，所以異常的學習還是很有必要的。”我說。

“那到底什么是異常呢?”三妹問。

“異常是指中斷程序正常執(zhí)行的一個不確定的事件。當異常發(fā)生時，程序的正常執(zhí)行流程就會被打斷。一般情況下，程序都會有很多條語句，如果沒有異常處理機制，前面的語句一旦出現(xiàn)了異常，后面的語句就沒辦法繼續(xù)執(zhí)行了。”

“有了異常處理機制后，程序在發(fā)生異常的時候就不會中斷，我們可以對異常進行捕獲，然后改變程序執(zhí)行的流程。”

“除此之外，異常處理機制可以保證我們向用戶提供友好的提示信息，而不是程序原生的異常信息——用戶根本理解不了。”

“不過，站在開發(fā)者的角度，我們更希望看到原生的異常信息，因為這有助于我們更快地找到 bug 的根源，反而被過度包裝的異常信息會干擾我們的視線。”

“Java 語言在一開始就提供了相對完善的異常處理機制，這種機制大大降低了編寫可靠程序的門檻，這也是 Java 之所以能夠流行的原因之一。”

“那導致程序拋出異常的原因有哪些呢?”三妹問。

比如說：

• 程序在試圖打開一個不存在的文件;
• 程序遇到了網(wǎng)絡連接問題;
• 用戶輸入了糟糕的數(shù)據(jù);
• 程序在處理算術問題時沒有考慮除數(shù)為 0 的情況;

等等等等。

挑個最簡單的原因來說吧。

public class Demo { 
    public static void main(String[] args) { 
        System.out.println(10/0); 
    } 
} 

這段代碼在運行的時候拋出的異常信息如下所示：

Exception in thread "main" java.lang.ArithmeticException: / by zero 
 at com.itwanger.s41.Demo.main(Demo.java:8) 

“你看，三妹，這個原生的異常信息對用戶來說，顯然是不太容易理解的，但對于我們開發(fā)者來說，簡直不要太直白了——很容易就能定位到異常發(fā)生的根源。”

“哦，我知道了。下一個問題，我經(jīng)?？吹揭恍┪恼吕锾岬?Exception 和 Error，二哥你能幫我解釋一下它們之間的區(qū)別嗎?”三妹問。

“這是一個好問題呀，三妹!”

從單詞的釋義上來看，error 為錯誤，exception 為異常，錯誤的等級明顯比異常要高一些。

從程序的角度來看，也的確如此。

Error 的出現(xiàn)，意味著程序出現(xiàn)了嚴重的問題，而這些問題不應該再交給 Java 的異常處理機制來處理，程序應該直接崩潰掉，比如說 OutOfMemoryError，內(nèi)存溢出了，這就意味著程序在運行時申請的內(nèi)存大于系統(tǒng)能夠提供的內(nèi)存，導致出現(xiàn)的錯誤，這種錯誤的出現(xiàn)，對于程序來說是致命的。

Exception 的出現(xiàn)，意味著程序出現(xiàn)了一些在可控范圍內(nèi)的問題，我們應當采取措施進行挽救。

比如說之前提到的 ArithmeticException，很明顯是因為除數(shù)出現(xiàn)了 0 的情況，我們可以選擇捕獲異常，然后提示用戶不應該進行除 0 操作，當然了，更好的做法是直接對除數(shù)進行判斷，如果是 0 就不進行除法運算，而是告訴用戶換一個非 0 的數(shù)進行運算。

“三妹，還能想到其他的問題嗎?”

“嗯，不用想，二哥，我已經(jīng)提前做好預習工作了。”三妹自信地說，“異常又可以分為 checked 和 unchecked，它們之間又有什么區(qū)別呢?”

“哇，三妹，果然又是一個好問題呢。”

checked 異常(檢查型異常)在源代碼里必須顯式地捕獲或者拋出，否則編譯器會提示你進行相應的操作;而 unchecked 異常(非檢查型異常)就是所謂的運行時異常，通常是可以通過編碼進行規(guī)避的，并不需要顯式地捕獲或者拋出。

“我先畫一幅思維導圖給你感受一下。”

首先，Exception 和 Error 都繼承了 Throwable 類。換句話說，只有 Throwable 類(或者子類)的對象才能使用 throw 關鍵字拋出，或者作為 catch 的參數(shù)類型。

面試中經(jīng)常問到的一個問題是，NoClassDefFoundError 和 ClassNotFoundException 有什么區(qū)別?

“三妹你知道嗎?”

“不知道，二哥，你解釋下唄。”

它們都是由于系統(tǒng)運行時找不到要加載的類導致的，但是觸發(fā)的原因不一樣。

• NoClassDefFoundError：程序在編譯時可以找到所依賴的類，但是在運行時找不到指定的類文件，導致拋出該錯誤;原因可能是 jar 包缺失或者調用了初始化失敗的類。
• ClassNotFoundException：當動態(tài)加載 Class 對象的時候找不到對應的類時拋出該異常;原因可能是要加載的類不存在或者類名寫錯了。

其次，像 IOException、ClassNotFoundException、SQLException 都屬于 checked 異常;像 RuntimeException 以及子類 ArithmeticException、ClassCastException、ArrayIndexOutOfBoundsException、NullPointerException，都屬于 unchecked 異常。

unchecked 異?？梢圆辉诔绦蛑酗@示處理，就像之前提到的 ArithmeticException 就是的;但 checked 異常必須顯式處理。

比如說下面這行代碼：

Class clz = Class.forName("com.itwanger.s41.Demo1"); 

如果沒做處理，比如說在 Intellij IDEA 環(huán)境下，就會提示你這行代碼可能會拋出 java.lang.ClassNotFoundException。

建議你要么使用 try-catch 進行捕獲：

try { 
    Class clz = Class.forName("com.itwanger.s41.Demo1"); 
} catch (ClassNotFoundException e) { 
    e.printStackTrace(); 
} 

注意打印異常堆棧信息的 printStackTrace() 方法，該方法會將異常的堆棧信息打印到標準的控制臺下，如果是測試環(huán)境，這樣的寫法還 OK，如果是生產(chǎn)環(huán)境，這樣的寫法是不可取的，必須使用日志框架把異常的堆棧信息輸出到日志系統(tǒng)中，否則可能沒辦法跟蹤。

要么在方法簽名上使用 throws 關鍵字拋出：

public class Demo1 { 
    public static void main(String[] args) throws ClassNotFoundException { 
        Class clz = Class.forName("com.itwanger.s41.Demo1"); 
    } 
} 

這樣做的好處是不需要對異常進行捕獲處理，只需要交給 Java 虛擬機來處理即可;壞處就是沒法針對這種情況做相應的處理。

“二哥，針對 checked 異常，我在知乎上看到一個帖子，說 Java 中的 checked 很沒有必要，這種異常在編譯期要么 try-catch，要么 throws，但又不一定會出現(xiàn)異常，你覺得這樣的設計有意義嗎?”三妹提出了一個很尖銳的問題。

“哇，這種問題問的好。”我不由得對三妹心生敬佩。

“的確，checked 異常在業(yè)界是有爭論的，它假設我們捕獲了異常，并且針對這種情況作了相應的處理，但有些時候，根本就沒法處理。”我說，“就拿上面提到的 ClassNotFoundException 異常來說，我們假設對其進行了 try-catch，可真的出現(xiàn)了 ClassNotFoundException 異常后，我們也沒多少的可操作性，再 Class.forName() 一次?”

另外，checked 異常也不兼容函數(shù)式編程，后面如果你寫 Lambda/Stream 代碼的時候，就會體驗到這種苦澀。

當然了，checked 異常并不是一無是處，尤其是在遇到 IO 或者網(wǎng)絡異常的時候，比如說進行 Socket 鏈接，我大致寫了一段：

public class Demo2 { 
    private String mHost; 
    private int mPort; 
    private Socket mSocket; 
    private final Object mLock = new Object(); 
 
    public void run() { 
    } 
 
    private void initSocket() { 
        while (true) { 
            try { 
                Socket socket = new Socket(mHost, mPort); 
                synchronized (mLock) { 
                    mSocket = socket; 
                } 
                break; 
            } catch (IOException e) { 
                e.printStackTrace(); 
            } 
        } 
    } 
} 

當發(fā)生 IOException 的時候，socket 就重新嘗試連接，否則就 break 跳出循環(huán)。意味著如果 IOException 不是 checked 異常，這種寫法就略顯突兀，因為 IOException 沒辦法像 ArithmeticException 那樣用一個 if 語句判斷除數(shù)是否為 0 去規(guī)避。

或者說，強制性的 checked 異常可以讓我們在編程的時候去思考，遇到這種異常的時候該怎么更優(yōu)雅的去處理。顯然，Socket 編程中，肯定是會遇到 IOException 的，假如 IOException 是非檢查型異常，就意味著開發(fā)者也可以不考慮，直接跳過，交給 Java 虛擬機來處理，但我覺得這樣做肯定更不合適。

“好了，三妹，關于異常處理機制這節(jié)就先講到這里吧。”我松了一口氣，對三妹說。

“好的，二哥，你去休息吧。”

“對了，三妹，我定個姑婆婆的外賣吧，晚上我們喝粥。”

“好呀，我要兩個豆沙包。”

本文轉載自微信公眾號「沉默王二」，可以通過以下二維碼關注。轉載本文請聯(lián)系沉默王二公眾號。