什麼是異常？

要了解受檢異常，首先要了解什麼是異常。

在Java中，異常是一套能夠一致地處理錯誤和恢復程式碼執行正常的機制。

在C語言中，他沒有異常處理機制。如果一個函數出現了異常情況，例如一個除法的函式，被除數輸入了0，這個時候需要把這個異常告訴函式呼叫者，一般情況下我們會通過返回一個特殊的值來告訴呼叫者出現異常，如返回-1。這是c語言常規的處理異常手法。這會引發另一個問題：我們需要在每次呼叫函式的時候，都進行條件判斷，看返回值是否出現了異常，這樣會讓我們的程式碼出現了非常多的if判斷語句。《Java程式設計思想》一書中講到：每次呼叫的時候都必須執行條件測試，以確定會產生何種結果。這使程式難以閱讀並且有可能降低執行效率，因此程式設計師們既不願意指出，也不願意處理異常

不僅程式碼不美觀和寫很多的程式碼，而且容易漏掉一些情況沒有進行判斷，沒有安全感。

這個是否需要有一套完整的異常處理機制，當出現問題的時候，把異常交給機制去處理，這樣我們就可以把處理異常的程式碼和正常的程式碼分開，且不擔心出現“漏網之魚”。因而我們需要：

一套統一的錯誤報告機制，可以減少程式碼量、程式碼簡潔的同時，能夠把錯誤進行統一處理，不會有漏網之魚。

關於這個問題在《Java程式設計思想》中是這樣說的：異常往往能降低錯誤處理程式碼的複雜度。如果不使用異常，那麼就必須檢查特定的錯誤，並在程式中的許多地方去處理它。而如果使用異常，那就不必在方法呼叫處進行檢查，因為異常機制將保證能夠捕獲這個錯誤。理想情況下，只需在一個地方處理錯誤，即所謂的異常處理程式中。這種方式不僅節省程式碼，而且把“描述在正常執行過程中做什麼事”的程式碼和“出了問題怎麼辦”的程式碼相分離。總之，與以前的錯誤處理方法相比，異常機制使程式碼的閱讀、編寫和除錯工作更加井井有條。Java異常機制比常規的錯誤報告機制還做到了：

我們可以在一個地方集中處理錯誤，把正常的程式碼處理邏輯和錯誤情況處理邏輯分離，使用程式碼的閱讀、編寫和除錯更加井井有條。

編譯時還是執行時？

熟悉Java開發的讀者知道Java異常機制擁有兩種大型別的異常：執行時異常和編譯時異常。

編譯時異常是在編譯的時候就能被檢查出來的異常，也被稱為受檢異常（Checked Exception）。如IOException。執行時異常就是在執行的時候才會被檢查的異常，如空指標異常。

而我們今天要討論的就是關於執行時異常。這兩種異常的本質差別是：檢查的時機。一般情況來說，錯誤能在編譯階段就被檢查出來是最好的，編譯器幫我們解決錯誤。然而情況也不一定都是這樣，因為處理異常需要我們寫出更多的程式碼。如果每次呼叫一個方法都需要處理所有的異常，那麼我們需要的工作量就太大了。例如空指標，我們知道幾乎每個方法都會丟擲這個異常，但是java並沒有強制我們去捕獲他。所以異常處理時機的分類是一個權衡的結果，既想讓編譯器盡多地幫我們檢查錯誤，又不能讓開發者程式碼編寫太多額外的程式碼，需要在這兩者之間找到一個最平衡的點。

“受檢異常”究竟可不可取？

這個問題其實爭論的歷史非常久，新型語言Kotlin中就把受檢異常去掉了。這樣我們就沒必要再去顯示捕獲任何異常。這在我第一次接觸kotlin的時候感覺簡直是一個噩夢：

因為我不知道呼叫的方法是否會丟擲異常、丟擲什麼異常，那麼我可能會忽略一些關鍵的異常沒有捕獲而導致程式碼的健壯性降低。

這也確實也是很多支援Java受檢異常開發者的心聲。有了受檢異常，那麼編譯器會提醒我們我們呼叫的這個方法會丟擲什麼異常，我們需要去使用try-catch來捕獲他，不會遺漏任何重要的異常。但事實真的如此嗎？

受檢異常真的能夠避免所有的異常嗎？不是的，我們依舊會出現空指標異常、非法狀態異常等，我們並不會去顯示捕獲這一類的異常，他在java中稱為執行時異常。那有讀者可能會說：受檢異常是可以讓我們避免一些方法顯示丟擲的異常，並不是要處理所有的錯誤。因而，我們必須呀承認一個事實：無論是否有受檢異常，均不能解決所有的異常，兩者的差別是編譯階段處理異常的數量。而這兩者的邊界是一種權衡的結果使用受檢異常，我們真的處理異常了嗎？

CLU 的設計師們認為：我們覺得強迫程式設計師在不知道該採取什麼措施的時候提供處理程式，是不現實的，只有在你知道如何處理的情況下才捕獲異常。

Stroustrup 這樣認為：這樣一來幾乎所有的函式都得提供異常說明了，也就都得重新編譯，而且還會妨礙它同其他語言的互動。這樣會迫使程式設計師違反異常處理機制的約束，他們會寫欺騙程式來掩蓋異常。這將給沒有注意到這些異常的人造成一種虛假的安全感

我們會發現現在的一種情況是：開發者捕獲異常之後，並沒有做具體的處理，而是對異常進行列印，或者乾脆不做任何處理，這是不符合異常的規則的。只有知道如何處理異常的情況下才去捕獲異常。如果捕獲異常之後卻不做任何處理，那麼實際上是把異常“吃了”。因為如果異常發生了，我們以為我們處理了，但事實上我們並沒有做任何處理，那麼這個錯誤就會一直存在，反而更不利於我們對程式碼健壯性的維護。有讀者可能會覺得，我們對於不知如何處理的異常可以往上拋，這會導致另一個問題：頂層介面的呼叫者會拿到非常多的異常型別而不知如何處理，最終只能向上拋給控制檯，從而使得整套異常機制完全失效。

我們知道異常機制的目的之一就是為了減少程式碼，不用每次呼叫一個方法都去進行條件判斷，而通過使用try-catch就可以把錯誤進行集中處理，把正常程式碼的邏輯和處理異常的邏輯分離開來，但是，受檢異常的存在，當我們即使呼叫一個Thread.sleep()方法都必須進行try-catch，又如IO流的開啟與關閉也都必須進行try-catch，，這樣的程式碼量其實又回到原地了，並沒有達到最初的目標：減少程式碼量。

《Java程式設計思想》一書認為：不在於編譯器是否會強制程式設計師去處理錯誤，而是要有一致的、使用異常來報告錯誤的模型；不在於什麼時候進行檢查，而是一定要有型別檢查。也就是說，必須強制程式使用正確的型別，至於這種強制施加於編譯時還是執行時，那倒沒關係。

即異常機制的重點在於一致的使用報告錯誤的模式和強制程式使用正確的型別。所以異常的存在，並不是要我們在編譯時把所有異常都處理了，而是我們可以統一處理異常且讓程式使用正確的型別。

我的觀點

上面講到我第一次接觸到kotlin的時候非常反感他把checkedException去掉了，這讓我非常沒有安全感，我的原因是：呼叫別人的介面的時候，這時候沒有編譯器的提醒我會遺漏關鍵的異常而導致程式碼的健壯性下降。但，正如上述，如果不知道如何處理異常而去捕獲異常，然後不做任何處理，這是在欺騙自己，獲得一種虛假的安全感。我們並沒有解決異常，而是把異常“吃了”，看起來程式並沒有崩潰，但事實上我們只是把異常藏起來了，沒有做任何處理。這種情況不如把異常往上拋到最頂層交給控制檯處理，我們知道程式崩潰了，那麼我們就知道得去解決這種異常，這樣才能真正促進程式碼的健壯性。

而向上拋會會導致另一個問題：頂層介面的呼叫者會拿到非常多的異常而不知道如何處理，再次向上拋，最終導致整個異常機制失效。而如果每一層都只處理自己感興趣的異常，剩下的異常就會自動拋到最頂層，程式碼會更加簡潔，我們也可以更加專注我們要處理的異常。

這兩個是我覺得“受檢異常”的硬傷，。而其他，如頻繁try-catch導致程式碼量增多，兩種型別的程式碼導致邏輯不連貫等，相對來說這屬於軟傷，在面對“可以在編譯階段解決更多的異常並沒有更強的說服力。

去掉受檢異常對於java工程師來說可能會很沒有安全感，因為：會存在一些異常沒有處理，他們就像一些炸彈，但不知道他們什麼時候爆炸。這確實是個問題，沒有受檢異常會有更多的異常留到執行時。但這個問題影響的效果可能並沒有我們想象中的那麼大。我們真正處理受檢異常機制提醒的異常其實並不多，正如我上面所講，如果我們捕獲異常之後只是“吃掉它”，那麼還不如拋給控制檯。

那麼“受檢異常”是不是就一無是處？我覺得不是的。受檢異常的目的是在編譯階段處理異常，去掉確實可以避免上述的兩個問題，且讓程式碼更加的簡潔。但是換之的是需要給測試人員更多的壓力和開發者自身的對程式碼健壯性的處理，需要有更多的精力去解決沒有“受檢異常”帶來的問題。不是有“全域性捕獲異常嗎”？頻繁的崩潰和維護，並不是一個好的解決方案，如果能在編碼階段就把隱藏的問題解決是最好不過的。

從我自己的經歷來說，我使用java和kotlin語言均開發過不同的專案，而沒有受檢異常並沒有給我帶來多大的障礙，反而不用使用try-catch讓我在編寫程式碼的時候更加舒適。但因我專案較小，所以可能並不能作為一個示例來證明，僅作為一個參考。而kotlin在這方面有一個我認為不好的特點：沒有異常宣告。即如果我想要看我呼叫的方法究竟會丟擲什麼異常時，需要一行一行程式碼去檢視，而無法通過異常宣告來得知。

所以，需要怎麼做？我認為這兩種解決方案各有千秋，看開發者如何取捨。而我個人覺得這是這種異常機制的限制，我們需要的是對異常機制的改進，如Java有了進行註解對異常進行忽略，這是一種進步。對這個問題的討論正如對洋蔥好不好吃的討論是差不多的，不同的團隊不同的需求取捨，會有不同的結果。討論這個問題更重要的是瞭解不同的解決方案有不同的優缺點，我們在開發的時候，可以發揮不同處理方案的優勢，注意不要踩坑。

沒有最好的語言，只有更好的開發者。如果我們能夠在每層都解決自己應該負責解決的異常，那麼頂層介面就不會有高達八十多種異常的出現。如果對每種異常捕獲之後都能夠做好對應的處理，而不是把異常“吃掉”來獲得虛假的安全感，那麼受檢異常也沒有那麼多的問題。如果我們可以更加規範地開發，那麼受檢異常，事實上問題也不會那麼多。簡單粗暴去除掉受檢異常，可以通過迎合大部分開發者的惰性和不規範來解決受檢異常存在的問題，但是這並不是最好的解決方法。所以我們能做的，不是去捍衛不同的立場，而是不斷地提升自己的程式碼規範，通過程式碼規範來增強程式碼的健壯性。

以上就是Java受檢異常的一些思考的詳細內容，更多關於Java受檢異常的資料請關注我們其它相關文章！