### [歷史](https://lingcoder.gitee.io/onjava8/#/book/15-Exceptions?id=%e5%8e%86%e5%8f%b2) 異常處理起源于 PL/1 和 Mesa 之類的系統中，后來又出現在 CLU、Smalltalk、Modula-3、Ada、Eiffel、C++、Python、Java 以及后 Java 語言 Ruby 和 C# 中。Java 的設計和 C++ 很相似，只是 Java 的設計者去掉了一些他們認為 C++設計得不好的東西。 為了能向程序員提供一個他們更愿意使用的錯誤處理和恢復的框架，異常處理機制很晚才被加入 C++ 標準化過程中，這是由 C++ 的設計者 Bjarne Stroustrup 所倡議。C++ 的異常模型主要借鑒了 CLU 的做法。然而，當時其他語言已經支持異常處理了：包括 Ada、Smalltalk（兩者都有異常處理，但是都沒有異常說明），以及 Modula-3（它既有異常處理也有異常說明）。 Liskov 和 Snyder 在他們的一篇討論該主題的獨創性論文中指出，用瞬時風格（transient fashion）報告錯誤的語言（如 C 中）有一個主要缺陷，那就是： > “....每次調用的時候都必須執行條件測試，以確定會產生何種結果。這使程序難以閱讀并且有可能降低運行效率，因此程序員們既不愿意指出，也不愿意處理異常。” 因此，異常處理的初衷是要消除這種限制，但是我們又從 Java 的“被檢查的異常”中看到了這種代碼。他們繼續寫道： > “....要求程序員把異常處理程序的代碼文本附接到會引發異常的調用上，這會降低程序的可讀性，使得程序的正常思路被異常處理給破壞了。” C++ 中異常的設計參考了 CLU 方式。Stroustrup 聲稱其目標是減少恢復錯誤所需的代碼。我想他這話是說給那些通常情況下都不寫 C 的錯誤處理的程序員們聽的，因為要把那么多代碼放到那么多地方實在不是什么好差事。所以他們寫 C 程序的習慣是，忽略所有的錯誤，然后使用調試器來跟蹤錯誤。這些程序員知道，使用異常就意味著他們要寫一些通常不用寫的、“多出來的”代碼。因此，要把他們拉到“使用錯誤處理”的正軌上，“多出來的”代碼決不能太多。我認為，評價 Java 的“被檢查的異常”的時候，這一點是很重要的。 C++ 從 CLU 那里還帶來另一種思想：異常說明。這樣，就可以用編程的方式在方法簽名中聲明這個方法將會拋出異常。異常說明有兩個目的：一個是“我的代碼會產生這種異常，這由你來處理”。另一個是“我的代碼忽略了這些異常，這由你來處理”。學習異常處理的機制和語法的時候，我們一直在關注“你來處理”部分，但這里特別值得注意的事實是，我們通常都忽略了異常說明所表達的完整含義。 C++ 的異常說明不屬于函數的類型信息。編譯時唯一要檢查的是異常說明是不是前后一致；比如，如果函數或方法會拋出某些異常，那么它的重載版本或者派生版本也必須拋出同樣的異常。與 Java 不同，C++ 不會在編譯時進行檢查以確定函數或方法是不是真的拋出異常，或者異常說明是不是完整（也就是說，異常說明有沒有精確描述所有可能被拋出的異常）。這樣的檢查只發生在運行期間。如果拋出的異常與異常說明不符，C++ 會調用標準類庫的 unexpected() 函數。 值得注意的是，由于使用了模板，C++ 的標準類庫實現里根本沒有使用異常說明。在 Java 中，對于泛型用于異常說明的方式存在著一些限制。