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

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

在这里，我会同意布洛赫先生的观点-
备选方案（

IllegalArgumentException

，

IllegalStateException

和

UnsupportedOperationException

）无法正确传达问题的严重性，因此呼叫者可能会错误地尝试抓住并处理此案。实际上，如果到达此行，则该程序已
损坏 ，唯一明智的 *** 作是退出。

这里的要点是枚举具有一组有限的值，因此应该不可能到达该

throw

行-仅当枚举的定义已更改而未同时固定此实例方法时，才会发生。

RuntimeException

实际上，方法（和枚举）本身已损坏，则抛出a
表示调用者犯了一个错误。明确提出一个

AssertionError

正确的值表明该方法预期的不变量已被违反。

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

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

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

该页面说

AssertionError

，建议使用来处理这些情况。他们

Verify

班上的评论还提供了一些有关选择异常的有用见解。在

AssertionError

似乎太强的情况下，加注

VerifyException

可以是一个不错的选择。

至于

Error

或的特定问题

RuntimeException

，实际上并不重要（两者都未选中，因此有可能在调用堆栈中向上传播而不会被捕获），但是呼叫者更有可能尝试从进行恢复

RuntimeException

。在这种情况下使应用程序崩溃是一项
功能
，因为否则我们将继续运行（目前）证明是错误的应用程序。呼叫者捕获和处理

AssertionError

（或

Error

或

Throwable

）的可能性肯定较小，但是呼叫者当然可以做他们想要的任何事情。