## [其他可選方式](https://lingcoder.gitee.io/onjava8/#/book/15-Exceptions?id=%e5%85%b6%e4%bb%96%e5%8f%af%e9%80%89%e6%96%b9%e5%bc%8f) 異常處理系統就像一個活門（trap door），使你能放棄程序的正常執行序列。當“異常情形”發生的時候，正常的執行已變得不可能或者不需要了，這時就要用到這個“活門"。異常代表了當前方法不能繼續執行的情形。開發異常處理系統的原因是，如果為每個方法所有可能發生的錯誤都進行處理的話，任務就顯得過于繁重了，程序員也不愿意這么做。結果常常是將錯誤忽略。應該注意到，開發異常處理的初衷是為了方便程序員處理錯誤。 異常處理的一個重要原則是“只有在你知道如何處理的情況下才捕獲異常"。實際上，異常處理的一個重要目標就是把處理錯誤的代碼同錯誤發生的地點相分離。這使你能在一段代碼中專注于要完成的事情，至于如何處理錯誤，則放在另一段代碼中完成。這樣一來，主要代碼就不會與錯誤處理邏輯混在一起，也更容易理解和維護。通過允許一個處理程序去處理多個出錯點，異常處理還使得錯誤處理代碼的數量趨于減少。 “被檢查的異常”使這個問題變得有些復雜，因為它們強制你在可能還沒準備好處理錯誤的時候被迫加上 catch 子句，這就導致了吞食則有害（harmful if swallowed）的問題： ~~~ try { // ... to do something useful } catch(ObligatoryException e) {} // Gulp! ~~~ 程序員們只做最簡單的事情（包括我自己，在本書第 1 版中也有這個問題），常常是無意中"吞食”了異常，然而一旦這么做，雖然能通過編譯，但除非你記得復查并改正代碼，否則異常將會丟失。異常確實發生了，但“吞食”后它卻完全消失了。因為編譯器強迫你立刻寫代碼來處理異常，所以這種看起來最簡單的方法，卻可能是最糟糕的做法。 當我意識到犯了這么大一個錯誤時，簡直嚇了一大跳，在本書第 2 版中，我在處理程序里通過打印棧軌跡的方法“修補”了這個問題（本章中的很多例子還是使用了這種方法，看起來還是比較合適的），雖然這樣可以跟蹤異常的行為，但是仍舊不知道該如何處理異常。這一節，我們來研究一下“被檢查的異常”及其并發癥，以及采用什么方法來解決這些問題。 這個話題看起來簡單，但實際上它不僅復雜，更重要的是還非常多變。總有人會頑固地堅持自己的立場，聲稱正確答案（也是他們的答案）是顯而易見的。我覺得之所以會有這種觀點，是因為我們使用的工具已經不是 ANSI 標準出臺前的像 C 那樣的弱類型語言，而是像 C++ 和 Java 這樣的“強靜態類型語言”（也就是編譯時就做類型檢查的語言），這是前者所無法比擬的。當剛開始這種轉變的時候（就像我一樣），會覺得它帶來的好處是那樣明顯，好像類型檢查總能解決所有的問題。在此，我想結合我自己的認識過程，告訴讀者我是怎樣從對類型檢查的絕對迷信變成持懷疑態度的，當然，很多時候它還是非常有用的，但是當它擋住我們的去路并成為障礙的時候，我們就得跨過去。只是這條界限往往并不是很清晰（我最喜歡的一句格言是：所有模型都是錯誤的，但有些是能用的）。