## [后記：Exception Bizarro World](https://lingcoder.gitee.io/onjava8/#/book/15-Exceptions?id=%e5%90%8e%e8%ae%b0%ef%bc%9aexception-bizarro-world) （來自于 2011 年的一篇博文） 我的朋友 James Ward 正在嘗試使用 JDBC 創建一些非常簡單的教學示例，但不斷被受檢查的異常所挫敗。他把 Howard Lewis Ship 的帖子“[被檢查的異常的悲劇](http://tapestryjava.blogspot.com/2011/05/tragedy-of-checked-exceptions.html)”指給我看。讓 James 尤其沮喪的是，即使做一些本來很簡單的事情，也必須在一個個環里跳來跳去。即使在`finally`塊中，他也不得不放入更多的`try-catch`子句，因為關閉連接也會導致異常。這些麻煩事的終點在哪里？本來只是做一些簡單的事，但卻被強制要求在一個個環里跳來跳去（注意，try-with-resources語句可以顯著改善這種情況）。 我們開始討論 Go 編程語言，我很著迷，因為Rob Pike等人。我們已經清楚地提出了許多關于語言設計的非常尖銳和基本的問題。基本上，他們已經采取了我們開始接受的有關語言的所有內容，并詢問“為什么？”關于每一種語言。學習這門語言真的讓你思考和懷疑。 我的印象是Go團隊不做任何臆斷，只有在明確一個特征是必須的時候才改進語言。他們似乎并不擔心做出破壞舊代碼的更改 ，因為他們創建了一個重寫工具，當做出更改的時候，重寫工具將為你重寫代碼。這使他們將語言變成一個前進的實驗，以發現真正需要的東西，而不是做 Big Upfront Design。 他們做出的最有趣的決定之一是完全排除異常。你沒有看錯 —— 他們不只是遺漏了經過檢查的異常情況。他們遺漏了所有異常情況。 替代方案非常簡單，起初它幾乎看起來像 C 一樣。因為 Go 從一開始就包含了元組，所以你可以輕松地從函數調用中返回兩個對象： ~~~ result, err := functionCall() ~~~ （`:=`告訴 Go 語言在這里定義`result`和`err`，并且推斷它們的類型） 就是這樣：對于每次調用，您都會獲得結果對象和錯誤對象。您可以立即檢查錯誤（這是典型的，因為如果某些操作失敗，則不太可能繼續下一步），或者稍后檢查是否有效。 起初這看起來很原始，是向“古代”的回歸。但到目前為止，我發現 Go 中的決定都經過了很好的考慮，值得深思。我的反應是因為我的大腦是異常的嗎？這會如何影響 James 的問題？ 它發生在我身上，我已經將異常處理視為一種并行執行路徑。如果你遇到異常，你會跳出正常的路徑進入這個并行執行路徑，這是一種“奇異世界”，你不再做你寫的東西，而是跳進 catch 和 finally 子句。正是這種替代執行路徑的世界導致了 James 抱怨的問題。 James 創造了一個對象。理想的情況下。對象創建不會導致潛在的異常，因此你必須抓住它們。你必須通過 try-finally 跟蹤創建以確保清理發生（Python團隊意識到清理不是一個特殊的條件，而是一個單獨的問題，所以他們創建了一個不同的語言構造 - 以便停止混淆二者）。任何導致異常的調用都會停止正常的執行路徑并跳轉（通過并行bizarro-world）到 catch 子句。 關于異常的一個基本假設是，我們通過在塊結束時收集所有錯誤處理代碼而不是在它們發生時處理錯誤來獲益。在這兩種情況下，我們都會停止正常執行，但是異常處理有一個自動機制，它會將你從正常的執行路徑中拋出，跳轉到你的并行異常世界，然后在正確的處理程序中再次彈出你。 跳入奇異的世界會給 James 帶來問題，它為所有程序員增加了更多的工作：因為你無法知道什么時候會發生什么事（你可以隨時進入奇怪的世界），你必須添加一些 try 塊來確保沒有任何東西從裂縫中滑落。您最終必須進行額外的編程以補償異常機制（它似乎類似于補償共享內存并發所需的額外工作）。 Go 團隊采取了大膽的舉動，質疑所有這些，并說，“讓我們毫無例外地嘗試它，看看會發生什么。”是的，這意味著你通常會在發生錯誤的地方處理錯誤，而不是最后將它們聚集在一起 try 塊。但這也意味著關于一件事的代碼是本地化的，也許這并不是那么糟糕。這也可能意味著您無法輕松組合常見的錯誤處理代碼（除非您確定了常用代碼并將其放入函數中，也不是那么糟糕）。但這絕對意味著您不必擔心有多個可能的執行路徑而且所有這些都需要。