在java中使用AssertionError和断言

Question

我以标准方式在Java中使用断言，在IDE中启用它们。因此，它们不是产品发布的一部分。最近，我看到了＜code＞抛出新的断言错误（）的代码示例

我的猜测是，主要区别在于断言的可选性，因此它们不会减慢生产性能，因此它们可以在代码中经常发生，但修复用户报告的几乎无法重现的错误更难。

对于AssertionError，正好相反。

我还发现断言错误在代码中不应该执行的地方更实用，而不是使用assert false//我们不应该在这里。特别是如果需要返回值。例如：

int getFoo(AnEnum a){
    if (a == AnEnum.ONE)
       return bar();
    else if (a == AnEnum.TWO)
       return SOME_VALUE;
    //else
    assert false; //throw new AssertionError();
    return -1; //not necessary when usin AssertionError
}

• 我的推理正确吗
• 两种方法的其他差异/用例/最佳实践/限制是什么
• 关于在＜code＞断言错误（以及断言类型）这一事实是否足以或多或少确保在发现错误时提供堆栈跟踪

Answer 1

我建议不要直接抛出＜code＞断言错误if子句包围它。你明白了
正如您不希望将一个神奇的数字硬编码到代码中的许多地方，并且可能会使用一个常量，您也不应该用许多重复来感染代码（即＜code＞抛出新的断言错误（…）

不过，这是关于断言的另一个词。我认为，在依赖生产代码中的断言错误之前，您应该三思。原因是断言错误非常通用。它有一个信息和一个原因，但差不多就是这样
考虑使用特定的＜code＞RuntimeException作为一个简单的例子，考虑您在问题中提到的一个案例，其中代码的某些部分是您不希望达到的。断言或＜code＞断言错误

Answer 2

在技术说明“使用断言编程：控制流不变量”中给出了以下代码：

void foo() {
    for (...) {
      if (...)
        return;
    }
    assert false; // Execution should never reach this point!
}

但也给出了以下说明：

注意：谨慎使用此技术。如果Java语言规范中定义的语句无法访问，如果您尝试断言未访问它，则会收到编译时错误。同样，一个可接受的替代方法是简单地抛出AssertionError。

当断言关闭时，您可能不希望抛出＜code＞断言错误。由于＜code＞AssertionError很可能没有替代物，因此即使它们关闭，我猜您也应该期望它们。

正如Jon Skeet所建议的那样，在无法访问的代码（即没有任何要评估的真实表达式）上抛出AssertionError永远不会减慢代码的速度，因此不会影响性能。

因此，最后抛出＜code＞断言错误