今天我要問你的問題是，請對比 Exception 和 Error，另外，運行時異常與一般異常有什麽區
別？

典型回答

Exception 和 Error 都是繼承了 Throwable 類，在 Java 中只有 Throwable 類型的實例才可以被拋出或者捕獲，它是異常處理機制的基本組成類型。

Exception 和 Error 體現了 Java 平臺設計者對不同異常分類情況的分類。Exception 是程序正常運行中，可以預料的意外情況，可能並且應該被捕獲，進行相應處理。

Error 是指正常情況下，不大可能出現的情況，絕大部分的 Error 都會導致程序（比如 JVM 自身）處於非正常的、不可恢復狀態。既然是非正常情況，所以不便於也不需要捕獲，常見的比如 OutOfMemoryError 之類，都是 Error 的子類。

Exception 又分為可檢查異常和不檢查異常（運行時異常），可檢查異常在源代碼必須顯示地進行捕獲處理，這是編譯器檢查地一部分。前面我介紹的不可查地 Error，是 Throwable 不是 Exception。

不檢查異常就是所謂地運行時異常，類似 NullPointerException、ArrayIndexOutOfBoundsException 之類，通常是可以編碼避免地邏輯錯誤，具體工具需要來判斷是否需要捕獲，並不會在編譯器強制要求。

其中有些子類型，最好重點理解一下，比如 NoClassDefFoundError 和
ClassNotFoundException 有什麽區別，這也是個經典的入門題目。

第二，理解 Java 語言中操作 Throwable 的元素和實踐。掌握最基本的語法是必須的，如 trycatch-finally 塊，throw、throws 關鍵字等。與此同時，也要懂得如何處理典型場景。
異常處理代碼比較繁瑣，比如我們需要寫很多千篇一律的捕獲代碼，或者在 finally 裏面做一些
資源回收工作。隨著 Java 語言的發展，引入了一些更加便利的特性，比如 try-with-resources
和 multiple catch，具體可以參考下面的代碼段。在編譯時期，會自動生成相應的處理邏輯，
比如，自動按照約定俗成 close 那些擴展了 AutoCloseable 或者 Closeable 的對象。

try {
// 業務代碼
// …
Thread.sleep(1000L);
} catch (Exception e) {
// Ignore it
}

上述代碼違反了異常處理地兩個基本原則

第一、盡量不要捕獲類似 Exception 這樣地通用異常，而是應該捕獲特定異常，在這裏是 Thread.sleep() 拋出地 InterruptedException。

這是因為在日常的開發和合作中，我們讀代碼的機會往往超過寫代碼，軟件工程是門協作的藝
術，所以我們有義務讓自己的代碼能夠直觀地體現出盡量多的信息，而泛泛的 Exception 之
類，恰恰隱藏了我們的目的。另外，我們也要保證程序不會捕獲到我們不希望捕獲的異常。比
如，你可能更希望 RuntimeException 被擴散出來，而不是被捕獲。

進一步講，除非深思熟慮了，否則不要捕獲 Throwable 或者 Error，這樣很難保證我們能夠正
確程序處理 OutOfMemoryError。

第二、不要生吞（swallow）異常。這是異常處理中要特別註意地事情，因為很可能會導致非常難以診斷地詭異情況。

生吞異常，往往是基於假設這段代碼可能不會發生，或者感覺忽略異常時無所謂地，但是千萬不要在產品代碼做這種假設！

如果我們不把異常拋出來，或者也沒有輸出到日誌（Logger）之類，程序可能在後續代碼以不可控地方式結束。沒人能夠輕易判斷究竟是哪裏拋出了異常，以及是什麽原因產生了異常。

再看看第二段代碼：

try {
// 業務代碼
// …
} catch (IOException e) {
e.printStackTrace();
}

這段代碼作為一段實驗代碼沒有任何問題，但是在產品代碼中，通常都不允許這樣處理。

我們來看看printStackTrace()的文檔，開頭就是“Prints this throwable and its backtrace
to the standard error stream”。 問題就在這，在稍微復雜一點的生產系統中，標誌出錯不是個合適的輸出選項，因為你很難判斷到底輸出到哪去了。

尤其對於分布式系統，如果發生異常，但是無法找到堆棧軌跡（stacktrace），這純屬是為診斷設置障礙。所以，最好使用產品日誌，詳細地輸出到日誌系統。

我們接下來看下面的代碼段，體會一下Throw early, catch late 原則。

public void readPreferences(String fileName){
//...perform operations...
InputStream in = new FileInputStream(fileName);
//...read the preferences file...
}

如果 fileName 是 null，那麽程序就會拋出 NullPointerException，但是由於沒有第一時間暴
露出問題，堆棧信息可能非常令人費解，往往需要相對復雜的定位。這個 NPE 只是作為例子，
實際產品代碼中，可能是各種情況，比如獲取配置失敗之類的。在發現問題的時候，第一時間拋
出，能夠更加清晰地反映問題。

我們可以修改一下，讓問題“throw early”，對應的異常信息就非常直觀了。

public void readPreferences(String filename) {
Objects. requireNonNull(filename);
//...perform other operations...
InputStream in = new FileInputStream(filename);
//...read the preferences file...
}

至於“catch late”，其實是我們經常苦惱的問題，捕獲異常後，需要怎麽處理呢？最差的處理
方式，就是我前面提到的“生吞異常”，本質上其實是掩蓋問題。如果實在不知道如何處理，可
以選擇保留原有異常的 cause 信息，直接再拋出或者構建新的異常拋出去。在更高層面，因為
有了清晰的（業務）邏輯，往往會更清楚合適的處理方式是什麽。

有的時候，我們會根據需要自定義異常，這個時候除了保證提供足夠的信息，還有兩點需要考
慮：
是否需要定義成 Checked Exception，因為這種類型設計的初衷更是為了從異常情況恢復，
作為異常設計者，我們往往有充足信息進行分類。
在保證診斷信息足夠的同時，也要考慮避免包含敏感信息，因為那樣可能導致潛在的安全問
題。如果我們看 Java 的標準類庫，你可能註意到類似 java.net.ConnectException，出錯信
息是類似“ Connection refused (Connection refused)”，而不包含具體的機器名、IP、
端口等，一個重要考量就是信息安全。類似的情況在日誌中也有，比如，用戶數據一般是不
可以輸出到日誌裏面的。
業界有一種爭論（甚至可以算是某種程度的共識），Java 語言的 Checked Exception 也許是個
設計錯誤，反對者列舉了幾點：
Checked Exception 的假設是我們捕獲了異常，然後恢復程序。但是，其實我們大多數情況
下，根本就不可能恢復。Checked Exception 的使用，已經大大偏離了最初的設計目的。
Checked Exception 不兼容 functional 編程，如果你寫過 Lambda/Stream 代碼，相信深
有體會。
很多開源項目，已經采納了這種實踐，比如 Spring、Hibernate 等，甚至反映在新的編程語言
設計中，比如 Scala 等。 如果有興趣，你可以參考：
http://literatejava.com/exceptions/checked-exceptions-javas-biggest-mistake/。
當然，很多人也覺得沒有必要矯枉過正，因為確實有一些異常，比如和環境相關的 IO、網絡
等，其實是存在可恢復性的，而且 Java 已經通過業界的海量實踐，證明了其構建高質量軟件的
能力。我就不再進一步解讀了，感興趣的同學可以點擊鏈接，觀看 Bruce Eckel 在 2018 年全球
軟件開發大會 QCon 的分享 Failing at Failing: How and Why We‘ve Been Nonchalantly
Moving Away From Exception Handling。
我們從性能角度來審視一下 Java 的異常處理機制，這裏有兩個可能會相對昂貴的地方：
try-catch 代碼段會產生額外的性能開銷，或者換個角度說，它往往會影響 JVM 對代碼進行
優化，所以建議僅捕獲有必要的代碼段，盡量不要一個大的 try 包住整段的代碼；與此同
時，利用異常控制代碼流程，也不是一個好主意，遠比我們通常意義上的條件語句
（if/else、switch）要低效。
Java 每實例化一個 Exception，都會對當時的棧進行快照，這是一個相對比較重的操作。如
果發生的非常頻繁，這個開銷可就不能被忽略了。

　　所以，對於部分追求極致性能的底層類庫，有種方式是嘗試創建不進行棧快照的 Exception。這
本身也存在爭議，因為這樣做的假設在於，我創建異常時知道未來是否需要堆棧。問題是，實際
上可能嗎？小範圍或許可能，但是在大規模項目中，這麽做可能不是個理智的選擇。如果需要堆
棧，但又沒有收集這些信息，在復雜情況下，尤其是類似微服務這種分布式系統，這會大大增加
診斷的難度。
當我們的服務出現反應變慢、吞吐量下降的時候，檢查發生最頻繁的 Exception 也是一種思
路。關於診斷後臺變慢的問題，我會在後面的 Java 性能基礎模塊中系統探討。
今天，我從一個常見的異常處理概念問題，簡單總結了 Java 異常處理的機制。並結合代碼，分
析了一些普遍認可的最佳實踐，以及業界最新的一些異常使用共識。最後，我分析了異常性能開
銷，希望對你有所幫助

Java核心-02 Exception和Error有什麽區別？