Java中Exception和Error的區別詳解

Posted on by

世界上存在永遠不會出錯的程序嗎？也許這隻會出現在程序員的夢中。隨著編程語言和軟件的誕生，異常情況就如影隨形地糾纏著我們，隻有正確的處理好意外情況，才能保證程序的可靠性。
java語言在設計之初就提供瞭相對完善的異常處理機制，這也是java得以大行其道的原因之一，因為這種機制大大降低瞭編寫和維護可靠程序的門檻。如今，異常處理機制已經成為現代編程語言的標配。
今天我要問你的問題是，請對比Exception和Error，另外，運行時異常與一般異常有什麼區別？
典型回答
Exception和Error都是繼承瞭Throwable類，在java中隻有Throwable類型的實例才可以被拋出（throw）或者捕獲（catch），他是異常處理機制的基本組成類型。
Exception和Error體現瞭java平臺設計者對不同異常情況的分類，Exception是程序正常運行中，可以預料的意外情況，可能並且應該被捕獲，進行相應的處理。
Error是指正常情況下，不大可能出現的情況，絕大部分的Error都會導致程序（比如JVM自身）處於非正常狀態，不可恢復狀態。既然是非正常情況，所以不便於也不需要捕獲，常見的比如OutOfMemoryError之類，都是Error的子類。
Exception又分為可檢查（checked）異常和不檢查（unchecked）異常，可檢查異常在源碼裡必須顯示的進行捕獲處理，這裡是編譯期檢查的一部分。前面我們介紹的不可查的Error，是Throwable不是Exception。
不檢查異常就是所謂的運行時異常，類似NullPointerException,ArrayIndexOutOfBoundsExceptin之類，通常是可以編碼避免的邏輯錯誤，具體根據需要來判斷是否需要捕獲，並不會在編譯器強制要求。

考點分析:
分析Exception和Error的區別，是從概念角度考察瞭java處理機制。總的來說，還處於理解的層面，面試者隻要闡述清楚就好瞭。
我們在日常的編程中，如何處理好異常是比較考驗功底的。我覺得需要掌握兩個方面：
第一，理解Throwable，Exception，Error的設計和分類。比如，掌握那些應用最為廣泛的子類，以及如何自定義異常等。
很多面試官會進一步追問一些細節，比如，你瞭解哪些Error，Exception或者RuntimeException?我畫瞭一個簡單的類圖，並列出來典型例子，可以給你作為參考，至少做到基本心裡有數。

Throwable類圖

其中有些子類型，最好重點理解一下，比如
NoClassDefFoundError和ClassNotFoundException有什麼區別，這也是一個經典的入門題目。
簡單總結就是，NoClassDefFoundError發生在編譯時對應的類可用，而運行時在Java的classpath路徑中，對應的類不可用導致的錯誤。
第二，理解java語言中操作Throwable的元素和實踐。掌握最基本的語法是必須的，比如try-catch-finally塊，throw，throws關鍵字等。與此同時，也要懂得如何處理典型場景。
異常處理代碼比較繁瑣，比如我們需要寫很多千篇一律的捕獲代碼，或者在finally裡面做一些資源回收工作。隨著java語言的發展，引入瞭一些更加便利的特性，比如try-with-resource和multiple catch,具體可以參考小面的代碼段，在編譯時期，會自動生成相應的處理邏輯，比如，自動按照約定俗成close那些擴展瞭AutoCloseable或者Closeable的對象。

try(BuffereReader br =new BufferReader(...);
    BufferedWriter writer = new BufferredWriter(...))
    {//dosomething}
catch(IOException | XException){//handle it}

知識擴展
前面談的大多是概念性的東西，下面我來談一些實踐中的選擇，我會結合一些代碼用例進行分析。
先看第一個，下面的代碼反應瞭異常處理中哪些不當之處？

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問題就在這裡，在稍微復雜一點的生產系統中，標準出錯（STERR）不是個合適的輸出選項，因為你很難判斷出到底輸出到哪裡去瞭。
尤其是分佈式系統，如果發生異常，但是無法找到堆棧軌跡（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 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等。
    當然，很多人覺得沒有必要矯枉過正，因為確實有一些異常，比如和環境相關的IO，網絡等，其實是存在可回復性的，而且java已經通過業界的海量實踐，證明瞭其結構高質量軟件的能力。我們就不再進一步解讀瞭。
    我們從性能角度來審視一下java的異常處理機制，這裡有兩個可能會相對昂貴的地方：
  • try-catch代碼段會產生額外的性能開銷，或者換個角度說，他往往會影響JVM對代碼進行優化，所以建議僅捕獲有必要的代碼段，盡量不要一個大的try包住整段的代碼；與此同時，利用異常控制代碼流程，也不是一個好主意，遠比我們通常意義上的條件語句（if/else,switch）要低效
  • java每實例化一個Exception，都會對當時的棧進行快照，這是一個相對比較重的操作。如果發生的非常的頻繁，這個開銷可能就不能被忽略瞭。
    所以，對於部分追求極致性能的底層類庫，有種方式是嘗試創建不進行快照的Exception.這本身也存在爭議，因為這樣做的假設在於，我創建異常時知道未來是否需要堆棧。問題是實際上可能嗎？小范圍或許可能，但是在大規模項目中，這麼做可能不是個理智的選擇。如果需要堆棧，但是沒有收集這些信息，在復雜情況下，尤其是類似微服務這種分佈式系統，這會大大增加診斷的難度。
    當我們的服務出現反應慢，吞吐量下降的時候，檢查發生最頻繁的Exception也是一種思路。關於診斷後臺變慢的問題，我們會在後面的java性能基礎模塊中系統討論。
    今天，我從一個常見的異常處理概念問題，簡單的總結瞭java異常處理機制，並結合代碼，分析瞭一些普遍認可的最佳實踐，以及業界最新的一些異常使用共識。最後，我分析瞭一下異常開銷，希望能對你有所幫助。
    一課一練
    關於我們討論的題目你做到心中有數瞭嗎？可以思考一個問題，對於異常處理編程，不同的編程范式也會影響到異常的處理策略，比如，現在非常火熱的反應式編程，因為其本身是異步，基於事件機制的，所以出現異常情況，決不能簡單的拋出；另外，由於代碼堆棧不再是同步調用那種垂直結構，這裡的異常處理和日志需要更加小心，我們看到的往往是特定executor的堆棧，而不是業務方法調用關系，對於這種情況，你有什麼好的辦法嗎？

到此這篇關於Java中Exception和Error的區別詳解的文章就介紹到這瞭,更多相關Java Exception和Error區別內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：