### [觀點](https://lingcoder.gitee.io/onjava8/#/book/15-Exceptions?id=%e8%a7%82%e7%82%b9) 首先，值得注意的是 Java 有效的發明了“被檢查的異常”（很明顯是受 C++ 異常說明的啟發，以及異常說明通常并不煩擾 C++ 程序員的事實），但是，這還只是一次嘗試，目前還沒有別的語言選擇復制這種做法。 其次，僅從示意性的例子和小程序來看，“被檢查的異常”的好處很明顯。但是當程序開始變大的時候，就會帶來一些微妙的問題。當然，程序不是一下就變大的，這有個過程。如果把不適用于大項目的語言用于小項目，當這些項目不斷膨脹時，突然有一天你會發現，原來可以管理的東西，現在已經變得無法管理了。這就是我所說的過多的類型檢查，特別是“被檢查的異常"所造成的問題。 看來程序的規模是個重要因素。由于很多討論都用小程序來做演示，因此這并不足以說明問題。一名 C# 的設計人員發現： > “僅從小程序來看，會認為異常說明能增加開發人員的效率，并提高代碼的質量；但考察大項目的時候，結論就不同了-開發效率下降了，而代碼質量只有微不足道的提高，甚至毫無提高”。 談到未被捕獲的異常的時候，CLU 的設計師們認為： > “我們覺得強迫程序員在不知道該采取什么措施的時候提供處理程序，是不現實的。” 在解釋為什么“函數沒有異常說明就表示可以拋出任何異常”的時候，Stroustrup 這樣認為： > “但是，這樣一來幾乎所有的函數都得提供異常說明了，也就都得重新編譯，而且還會妨礙它同其他語言的交互。這樣會迫使程序員違反異常處理機制的約束，他們會寫欺騙程序來掩蓋異常。這將給沒有注意到這些異常的人造成一種虛假的安全感。” 我們已經看到這種破壞異常機制的行為了-就在 Java 的“被檢查的異常”里。 Martin Fowler（UML Distilled，Refactoring 和 Analysis Patterns 的作者）給我寫了下面這段話： > “...總體來說，我覺得異常很不錯，但是 Java 的”被檢查的異常“帶來的麻煩比好處要多。” 我現在認為 Java 的重要進步是統一了錯誤報告模式，所有錯誤都用異常來報告。這沒有在 C++ 中發生，原因是為了向后兼容 C ，直接忽略錯誤的舊模式在 C++ 中依然是可用的。如果想使用異常，可以始終用異常來報告，如果不想這樣做，異常可以拋到最高的級別（比如控制臺）。當 Java 修改 C++ 的模式來讓異常成為報告錯誤的唯一方式時，受檢查的異常的額外限制可能就變得不那么必要了。 過去，我曾堅定地認為“被檢查的異常”和強靜態類型檢查對開發健壯的程序是非常必要的。但是，我看到的以及我使用一些動態（類型檢查）語言的親身經歷告訴我，這些好處實際上是來自于： 1. 不在于編譯器是否會強制程序員去處理錯誤，而是要有一致的、使用異常來報告錯誤的模型。 2. 不在于什么時候進行檢查，而是一定要有類型檢查。也就是說，必須強制程序使用正確的類型，至于這種強制施加于編譯時還是運行時，那倒沒關系。 此外，減少編譯時施加的約束能顯著提高程序員的編程效率。事實上，反射和泛型就是用來補償靜態類型檢查所帶來的過多限制，在本書很多例子中都會見到這種情形。 我已經聽到有人在指責了，他們認為這種言論會令我名譽掃地，會讓文明墮落，會導致更高比例的項目失敗。他們的信念是應該在編譯時指出所有錯誤，這樣才能挽救項目，這種信念可以說是無比堅定的；其實更重要的是要理解編譯器的能力限制。在[http://MindView.net/Books/BetterJava](http://mindview.net/Books/BetterJava)上的補充材料中，我強調了自動構建過程和單元測試的重要性，比起把所有的東西都說成是語法錯誤，它們的效果可以說是事半功倍。下面這段話是至理名言： > 好的程序設計語言能幫助程序員寫出好程序，但無論哪種語言都避免不了程序員用它寫出壞程序。 不管怎么說，要讓 Java 把“被檢查的異常”從語言中去除，這種可能性看來非常渺茫。對語言來說，這個變化可能太激進了點，況且 Sun 的支持者們也非常強大。Sun 有完全向后兼容的歷史和策略，實際上所有 Sun 的軟件都能在 Sun 的硬件上運行，無論它們有多么古老。然而，如果發現有些“被檢查的異常”擋住了路，尤其是發現你不得不去對付那些不知道該如何處理的異常，還是有些辦法的。