一尘不染

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

java

通过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,是否是个好习惯,还是应该避免,即使有可能?(我猜阅读文档是后者)


阅读 277

收藏
2020-12-03

共1个答案

一尘不染

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

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

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

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

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

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

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

2020-12-03