“嗨，阿米戈！”
“嗨，艾莉！生活怎么样？”
“太好了，谢谢。你好吗？”
“太好了，今天早上向我解释了大量新事物。”
“嗯，太好了，你不累吗？”
“是的，就是这样。我有点累了。”
“那你就走运了。我今天想讲一个大而复杂的话题，但在最后一刻我改变了主意，决定讲一个小而简单的话题。”
“小而简单？我准备好了。”
“今天我们将详细研究异常的主题。”
“你是在谈论错误处理吗？”
“你不应该认为异常是错误。异常更像是‘发生了意外的事情’的报告。根据这些报告，你可以提出替代行动。”
“一切都是关于方法的。 当你调用一个方法时，它承诺会做它被调用要做的事情。 ”
“当一个方法，无论出于何种原因，不能做它被调用要做的事情时，它必须让调用者知道。”
“换句话说，可能发生的最糟糕的事情是一种方法不执行它的工作并且不告诉任何人。没有比这更糟糕的了。当这种情况发生时，你会失去对情况的控制。 ”
“当你是一名新程序员时，似乎你只是调用方法，它们肯定会按照你的要求去做。”
“当你是一名经验丰富的程序员时，你就会知道可能有许多因素会影响一个方法完成其工作的能力，并且有很多情况可能会阻止一个方法完成其工作。”
“从程序员的角度来看，如果程序在遇到错误时终止，比程序遇到错误然后继续（错误地）工作而用户没有意识到发生了什么要好一千倍。”
“所以显示错误的程序可能比程序关闭并丢失所有数据更糟糕？”
“是什么让你认为程序只是错误地显示了一些东西？也许程序有很多错误，你的所有数据都将无法挽回地丢失？假设你输入了 3 个小时的文本，但没有任何内容会被保存，因为两分钟后发生的错误。”
“当新手程序员遇到异常时，他会感到沮丧。”
“但实际上，异常情况揭示了他应该预见但没有预见到的所有可能情况。”
“你可以选择不处理异常，这会让你成为一个糟糕的程序员。但如果你的方法不抛出异常，那么你根本就不是程序员——因为你没有理解这个简单的事实：”
“一个方法要么做它被写来做的事情，要么抛出异常。没有第三种选择！”
“好，我相信你，我保证用例外。”
“太好了。那我给你讲一下异常的层次结构：”
“异常层次结构基于四个类。”
“最低的基类是Throwable。”
“ Error和Exception类继承了它。”
“ RuntimeException继承Exception。”
“ Error类是 JVM 错误的基类，例如StackOverFlow、OutOfMemory ……”
“程序通常无法从此类错误中恢复，从而导致程序终止。”
“的确，如果没有足够的内存让程序继续正常运行，或者出现了堆栈溢出，怎么办？”
“ Exception是程序抛出的所有普通异常的基类。RuntimeException 是一种特殊的Exception，其规则略有不同。”
“这些是什么？”
“这就是我现在要解释的。”
“您可能还记得，异常分为两类：已检查和未检查。”
“如果一个方法抛出已检查的异常，那么调用它的方法必须将调用包装在一个try-catch块中。好吧，或者通过在方法签名中明确指示抛出来重新抛出异常（给它的调用者） 。”
“这些规则/限制不适用于未经检查的异常。”
“所以，所有继承Exception的异常都被认为是checked。除了继承RuntimeException的异常被认为是unchecked。”
“嗯嗯。我记得你之前跟我说过类似的话。”
“朋友！他们在每次面试中都会询问异常层次结构。我会再说一遍——每次面试。你需要完全了解这个话题。”
“好的。我会再读一遍然后弄清楚。谢谢你帮助我，艾莉。”
GO TO FULL VERSION