在这里，我会同意布洛赫先生的观点-
备选方案（
IllegalArgumentException，
IllegalStateException和
UnsupportedOperationException）无法正确传达问题的严重性，因此呼叫者可能会错误地尝试抓住并处理此案。实际上，如果到达此行，则该程序已
损坏 ，唯一明智的操作是退出。
这里的要点是枚举具有一组有限的值，因此应该不可能到达该
throw行-仅当枚举的定义已更改而未同时固定此实例方法时，才会发生。
RuntimeException实际上，方法（和枚举）本身已损坏，则抛出a
表示调用者犯了一个错误。明确提出一个
AssertionError正确的值表明该方法预期的不变量已被违反。
番石榴有一篇很有帮助的文章，其中对何时引发不同类型的异常进行了细分。他们写：
传统的 断言
是一种检查，只有在类本身（包含检查）被破坏时，检查才应该失败。（在某些情况下，这可以扩展到包。）它们可以采取各种形式，包括后置条件，类不变式和内部前提条件（基于非公共方法）。一个 不可能的条件检查
是一个不可能失败，除非周围的代码后来被修改，或者我们对平台的行为最深的假设受到严重侵犯。这些应该是不必要的，但由于编译器无法识别一条语句是无法到达的，或者因为我们对编译器无法推断的控制流有所了解，因此通常会被强制执行。
该页面说
AssertionError，建议使用来处理这些情况。他们
Verify班上的评论还提供了一些有关选择异常的有用见解。在
AssertionError似乎太强的情况下，加注
VerifyException可以是一个不错的选择。
至于
Error或的特定问题
RuntimeException，实际上并不重要（两者都未选中，因此有可能在调用堆栈中向上传播而不会被捕获），但是呼叫者更有可能尝试从进行恢复
RuntimeException。在这种情况下使应用程序崩溃是一项
功能
，因为否则我们将继续运行（目前）证明是错误的应用程序。呼叫者捕获和处理
AssertionError（或
Error或
Throwable）的可能性肯定较小，但是呼叫者当然可以做他们想要的任何事情。
