在Java中积极抛出AssertionError是一个好习惯吗？

Question

通过Joshua Bloch的“ Effective Java-Second Edition”，我偶然发现了第152页上的以下代码：

double apply(double x, double y) {
    switch(this) {
        case PLUS:   return x + y;
        case MINUS:  return x - y;
        case TIMES:  return x * y;
        case DIVIDE: return x / y;
    }
    throw new AssertionError("Unknown op: " + this);
}

现在令我困惑的是，AssertionError主动抛出该异常。那被认为是好的做法吗？据我所知，断言用于避免与代码发生干扰，因此在启动Java编程时未启用断言且因此未执行断言语句时，行为不会改变。如果我AssertionException在没有启用断言的情况下运行程序时得到一个提示，我就会很困惑。

尽管我知道示例案例可能经常发生，但是您分析了两个不同的选项，如果都不选择，则应该抛出异常。

那么AssertionException在这里扔一个是好习惯，还是在其他地方扔一个更好？如果是这样，哪一个最合适？也许IllegalArgumentException吧？

编辑以澄清问题：我的问题不是关于是否应该在Error此处扔一个，而如果我们想扔一个Exception或一个Error，应该是哪个？主动抛出AssertionErrors
是一种好习惯吗？文档说 Thrown表示断言失败 ，所以我觉得我们不应该主动抛出该 断言 。那是对的吗？

第二次修改：明确的问题：主动抛出AssertionError，是否是个好习惯，还是应该避免，即使有可能？（我猜阅读文档是后者）

Answer 1

在这里，我会同意布洛赫先生的观点-
备选方案（IllegalArgumentException，IllegalStateException和UnsupportedOperationException）无法正确传达问题的严重性，因此呼叫者可能会错误地尝试抓住并处理此案。实际上，如果到达此行，则该程序已
损坏 ，唯一明智的操作是退出。

这里的要点是枚举具有一组有限的值，因此应该不可能到达该throw行-仅当枚举的定义已更改而未同时固定此实例方法时，才会发生。RuntimeException实际上，方法（和枚举）本身已损坏，则抛出a
表示调用者犯了一个错误。明确提出一个AssertionError正确的值表明该方法预期的不变量已被违反。

番石榴有一篇很有帮助的文章，其中对何时引发不同类型的异常进行了细分。他们写：

传统的 断言
是一种检查，只有在类本身（包含检查）被破坏时，检查才应该失败。（在某些情况下，这可以扩展到包。）它们可以采取各种形式，包括后置条件，类不变式和内部前提条件（基于非公共方法）。

一个 不可能的条件检查
是一个不可能失败，除非周围的代码后来被修改，或者我们对平台的行为最深的假设受到严重侵犯。这些应该是不必要的，但由于编译器无法识别一条语句是无法到达的，或者因为我们对编译器无法推断的控制流有所了解，因此通常会被强制执行。

该页面说AssertionError，建议使用来处理这些情况。他们Verify班上的评论还提供了一些有关选择异常的有用见解。在AssertionError似乎太强的情况下，加注VerifyException可以是一个不错的选择。

至于Error或的特定问题RuntimeException，实际上并不重要（两者都未选中，因此有可能在调用堆栈中向上传播而不会被捕获），但是呼叫者更有可能尝试从进行恢复RuntimeException。在这种情况下使应用程序崩溃是一项
功能
，因为否则我们将继续运行（目前）证明是错误的应用程序。呼叫者捕获和处理AssertionError（或Error或Throwable）的可能性肯定较小，但是呼叫者当然可以做他们想要的任何事情。