什么是異常？

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

在Java中，異常是一套能夠一致地處理錯誤和恢復(fù)代碼運行正常的機制。

在C語言中，他沒有異常處理機制。如果一個函數(shù)出現(xiàn)了異常情況，例如一個除法的函數(shù)，被除數(shù)輸入了0，這個時候需要把這個異常告訴函數(shù)調(diào)用者，一般情況下我們會通過返回一個特殊的值來告訴調(diào)用者出現(xiàn)異常，如返回-1。這是c語言常規(guī)的處理異常手法。這會引發(fā)另一個問題：我們需要在每次調(diào)用函數(shù)的時候，都進行條件判斷，看返回值是否出現(xiàn)了異常，這樣會讓我們的代碼出現(xiàn)了非常多的if判斷語句?！?a target="_blank" href="http://www.dbjr.com.cn/books/75542.html">Java編程思想》一書中講到：每次調(diào)用的時候都必須執(zhí)行條件測試，以確定會產(chǎn)生何種結(jié)果。這使程序難以閱讀并且有可能降低運行效率，因此程序員們既不愿意指出，也不愿意處理異常

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

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

一套統(tǒng)一的錯誤報告機制，可以減少代碼量、代碼簡潔的同時，能夠把錯誤進行統(tǒng)一處理，不會有漏網(wǎng)之魚。

關(guān)于這個問題在《Java編程思想》中是這樣說的：異常往往能降低錯誤處理代碼的復(fù)雜度。如果不使用異常，那么就必須檢查特定的錯誤，并在程序中的許多地方去處理它。而如果使用異常，那就不必在方法調(diào)用處進行檢查，因為異常機制將保證能夠捕獲這個錯誤。理想情況下，只需在一個地方處理錯誤，即所謂的異常處理程序中。這種方式不僅節(jié)省代碼，而且把“描述在正常執(zhí)行過程中做什么事”的代碼和“出了問題怎么辦”的代碼相分離?？傊?，與以前的錯誤處理方法相比，異常機制使代碼的閱讀、編寫和調(diào)試工作更加井井有條。Java異常機制比常規(guī)的錯誤報告機制還做到了：

我們可以在一個地方集中處理錯誤，把正常的代碼處理邏輯和錯誤情況處理邏輯分離，使用代碼的閱讀、編寫和調(diào)試更加井井有條。

編譯時還是運行時？

熟悉Java開發(fā)的讀者知道Java異常機制擁有兩種大類型的異常：運行時異常和編譯時異常。

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

而我們今天要討論的就是關(guān)于運行時異常。這兩種異常的本質(zhì)差別是：檢查的時機。一般情況來說，錯誤能在編譯階段就被檢查出來是最好的，編譯器幫我們解決錯誤。然而情況也不一定都是這樣，因為處理異常需要我們寫出更多的代碼。如果每次調(diào)用一個方法都需要處理所有的異常，那么我們需要的工作量就太大了。例如空指針，我們知道幾乎每個方法都會拋出這個異常，但是java并沒有強制我們?nèi)ゲ东@他。所以異常處理時機的分類是一個權(quán)衡的結(jié)果，既想讓編譯器盡多地幫我們檢查錯誤，又不能讓開發(fā)者代碼編寫太多額外的代碼，需要在這兩者之間找到一個最平衡的點。

“受檢異?！本烤箍刹豢扇?？

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

因為我不知道調(diào)用的方法是否會拋出異常、拋出什么異常，那么我可能會忽略一些關(guān)鍵的異常沒有捕獲而導(dǎo)致代碼的健壯性降低。

這也確實也是很多支持Java受檢異常開發(fā)者的心聲。有了受檢異常，那么編譯器會提醒我們我們調(diào)用的這個方法會拋出什么異常，我們需要去使用try-catch來捕獲他，不會遺漏任何重要的異常。但事實真的如此嗎？

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

CLU 的設(shè)計師們認(rèn)為：我們覺得強迫程序員在不知道該采取什么措施的時候提供處理程序，是不現(xiàn)實的，只有在你知道如何處理的情況下才捕獲異常。

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

我們會發(fā)現(xiàn)現(xiàn)在的一種情況是：開發(fā)者捕獲異常之后，并沒有做具體的處理，而是對異常進行打印，或者干脆不做任何處理，這是不符合異常的規(guī)則的。只有知道如何處理異常的情況下才去捕獲異常。如果捕獲異常之后卻不做任何處理，那么實際上是把異?！俺粤恕?。因為如果異常發(fā)生了，我們以為我們處理了，但事實上我們并沒有做任何處理，那么這個錯誤就會一直存在，反而更不利于我們對代碼健壯性的維護。有讀者可能會覺得，我們對于不知如何處理的異?？梢酝蠏?，這會導(dǎo)致另一個問題：頂層接口的調(diào)用者會拿到非常多的異常類型而不知如何處理，最終只能向上拋給控制臺，從而使得整套異常機制完全失效。

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

《Java編程思想》一書認(rèn)為：不在于編譯器是否會強制程序員去處理錯誤，而是要有一致的、使用異常來報告錯誤的模型；不在于什么時候進行檢查，而是一定要有類型檢查。也就是說，必須強制程序使用正確的類型，至于這種強制施加于編譯時還是運行時，那倒沒關(guān)系。

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

我的觀點

上面講到我第一次接觸到kotlin的時候非常反感他把checkedException去掉了，這讓我非常沒有安全感，我的原因是：調(diào)用別人的接口的時候，這時候沒有編譯器的提醒我會遺漏關(guān)鍵的異常而導(dǎo)致代碼的健壯性下降。但，正如上述，如果不知道如何處理異常而去捕獲異常，然后不做任何處理，這是在欺騙自己，獲得一種虛假的安全感。我們并沒有解決異常，而是把異?！俺粤恕?，看起來程序并沒有崩潰，但事實上我們只是把異常藏起來了，沒有做任何處理。這種情況不如把異常往上拋到最頂層交給控制臺處理，我們知道程序崩潰了，那么我們就知道得去解決這種異常，這樣才能真正促進代碼的健壯性。

而向上拋會會導(dǎo)致另一個問題：頂層接口的調(diào)用者會拿到非常多的異常而不知道如何處理，再次向上拋，最終導(dǎo)致整個異常機制失效。而如果每一層都只處理自己感興趣的異常，剩下的異常就會自動拋到最頂層，代碼會更加簡潔，我們也可以更加專注我們要處理的異常。

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

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

那么“受檢異?！笔遣皇蔷鸵粺o是處？我覺得不是的。受檢異常的目的是在編譯階段處理異常，去掉確實可以避免上述的兩個問題，且讓代碼更加的簡潔。但是換之的是需要給測試人員更多的壓力和開發(fā)者自身的對代碼健壯性的處理，需要有更多的精力去解決沒有“受檢異?！睅淼膯栴}。不是有“全局捕獲異常嗎”？頻繁的崩潰和維護，并不是一個好的解決方案，如果能在編碼階段就把隱藏的問題解決是最好不過的。

從我自己的經(jīng)歷來說，我使用java和kotlin語言均開發(fā)過不同的項目，而沒有受檢異常并沒有給我?guī)矶啻蟮恼系K，反而不用使用try-catch讓我在編寫代碼的時候更加舒適。但因我項目較小，所以可能并不能作為一個示例來證明，僅作為一個參考。而kotlin在這方面有一個我認(rèn)為不好的特點：沒有異常聲明。即如果我想要看我調(diào)用的方法究竟會拋出什么異常時，需要一行一行代碼去查看，而無法通過異常聲明來得知。

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

沒有最好的語言，只有更好的開發(fā)者。如果我們能夠在每層都解決自己應(yīng)該負(fù)責(zé)解決的異常，那么頂層接口就不會有高達八十多種異常的出現(xiàn)。如果對每種異常捕獲之后都能夠做好對應(yīng)的處理，而不是把異?！俺缘簟眮慝@得虛假的安全感，那么受檢異常也沒有那么多的問題。如果我們可以更加規(guī)范地開發(fā)，那么受檢異常，事實上問題也不會那么多。簡單粗暴去除掉受檢異常，可以通過迎合大部分開發(fā)者的惰性和不規(guī)范來解決受檢異常存在的問題，但是這并不是最好的解決方法。所以我們能做的，不是去捍衛(wèi)不同的立場，而是不斷地提升自己的代碼規(guī)范，通過代碼規(guī)范來增強代碼的健壯性。

以上就是Java受檢異常的一些思考的詳細內(nèi)容，更多關(guān)于Java受檢異常的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論