“嗨，阿米戈！”
“嗨，艾莉！生活怎麼樣？”
“太好了，謝謝。你好嗎？”
“太好了，今天早上向我解釋了大量新事物。”
“嗯，太好了，你不累嗎？”
“是的，就是這樣。我有點累了。”
“那你就走運了。我今天想講一個大而復雜的話題，但在最後一刻我改變了主意，決定講一個小而簡單的話題。”
“小而簡單？我準備好了。”
“今天我們將詳細研究異常的主題。”
“你是在談論錯誤處理嗎？”
“你不應該認為異常是錯誤。異常更像是‘發生了意外的事情’的報告。根據這些報告，你可以提出替代行動。”
“一切都是關於方法的。 當你調用一個方法時，它承諾會做它被調用要做的事情。 ”
“當一個方法，無論出於何種原因，不能做它被調用要做的事情時，它必須讓調用者知道。”
“換句話說，可能發生的最糟糕的事情是一種方法不執行它的工作並且不告訴任何人。沒有比這更糟糕的了。當這種情況發生時，你會失去對情況的控制。 ”
“當你是一名新程序員時，似乎你只是調用方法，它們肯定會按照你的要求去做。”
“當你是一名經驗豐富的程序員時，你就會知道可能有許多因素會影響一個方法完成其工作的能力，並且有很多情況可能會阻止一個方法完成其工作。”
“從程序員的角度來看，如果程序在遇到錯誤時終止，比程序遇到錯誤然後繼續（錯誤地）工作而用戶沒有意識到發生了什麼要好一千倍。”
“所以顯示錯誤的程序可能比程序關閉並丟失所有數據更糟糕？”
“是什麼讓你認為程序只是錯誤地顯示了一些東西？也許程序有很多錯誤，你的所有數據都將無法挽回地丟失？假設你輸入了 3 個小時的文本，但沒有任何內容會被保存，因為兩分鐘後發生的錯誤。”
“當新手程序員遇到異常時，他會感到沮喪。”
“但實際上，異常情況揭示了他應該預見但沒有預見到的所有可能情況。”
“你可以選擇不處理異常，這會讓你成為一個糟糕的程序員。但如果你的方法不拋出異常，那麼你根本就不是程序員——因為你沒有理解這個簡單的事實：”
“一個方法要么做它被寫來做的事情，要么拋出異常。沒有第三種選擇！”
“好，我相信你，我保證用例外。”
“太好了。那我給你講講異常的層級吧：”
“異常層次結構基於四個類。”
“最低的基類是Throwable。”
“ Error和Exception類繼承了它。”
“ RuntimeException繼承Exception。”
“ Error類是 JVM 錯誤的基類，例如StackOverFlow、OutOfMemory ……”
“程序通常無法從此類錯誤中恢復，從而導致程序終止。”
“的確，如果沒有足夠的內存讓程序繼續正常運行，或者出現了堆棧溢出，怎麼辦？”
“ Exception是程序拋出的所有普通異常的基類。RuntimeException 是一種特殊的Exception，其規則略有不同。”
“這些是什麼？”
“這就是我現在要解釋的。”
“您可能還記得，異常分為兩類：已檢查和未檢查。”
“如果一個方法拋出已檢查的異常，那麼調用它的方法必須將調用包裝在一個try-catch塊中。好吧，或者通過在方法簽名中明確指示拋出來重新拋出異常（給它的調用者）。”
“這些規則/限制不適用於未經檢查的異常。”
“所以，所有繼承Exception的異常都被認為是checked。除了繼承RuntimeException的異常被認為是unchecked。”
“嗯嗯。我記得你之前跟我說過類似的話。”
“朋友！他們在每次面試中都會詢問異常層次結構。我會再說一遍——每次面試。你需要完全了解這個話題。”
“好的。我會再讀一遍然後弄清楚。謝謝你幫助我，艾莉。”
GO TO FULL VERSION