如何在java中在默认情况下没有启用断言?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (75)

我的问题是从语言设计的角度来看

为什么断言处理方式不同,即它引发错误而不是异常,默认情况下不启用等等。

它似乎很优雅(非常主观的意见),易于阅读(再次主观)进行验证,还有工具(IDE)可以对其进行实时评估并根据断言提供警告。

提问于
用户回答回答于

会引发错误,因为断言违规的严重程度足够高

Exception的一个例子是ArrayIndexOutOfBounds。在某些情况下这可能是合理的,甚至可能期望(并处理)这种情况,但是断言违规是(例如内存不足)你没想到或者你想要处理的事情。这是一个错误,没有任何借口,默认情况下不启用断言,因为它们应始终为fullfilled。您可以让他们对此进行测试,但随后您“知道”(据您所知)他们没有被违反。因此,您不需要每次在生产代码中检查条件(可能是性能密集型)。Java中断言的好处是,当未启用断言时,实际执行检查的代码永远不会执行。

例如:

if (!doComplexChecks()) throw new AssertionError("Damn!");

可能需要花费大量时间,并且您希望在单元测试或调试时验证这一点,但在生产中您只是不希望这样。

但是这段代码

assert doComplexChecks();

只有在启用断言时才会执行,这样可以节省大量的生产代码时间

用户回答回答于

我要说的原因是Java的默认设置是为了构建软件的“发布”版本 - 如果用户需要构建你的代码,他们将使用提供的默认值,如果你是开发人员,并希望有更好的报告,你总是可以做一些额外的努力。

通常不希望发布具有发布版本的断言。为什么?你总是可以设计你的代码来执行一些不令人不安的背景错误处理,投入AssertionError用户面对并不总是那样。

大多数时候我看到它们被用作额外的代码测试 - 当你运行回归测试并且代码覆盖率很高时,没有断言错误表明你的代码中没有(显而易见的)错误。如果发生某些情况,可以从堆栈跟踪中推断出出现了什么问题以及原因。另一方面,客户不应该看到描述性错误信息。

那么你应该如何使用它们呢?根据我的经验,应该设计代码以不使用断言来执行错误处理。如果你想在某个地方抛出异常,请自己明确抛出它。一旦代码可以处理自己,你可以添加断言来检查前置条件和后置条件以及不变量 - 所以基本上用它们来检查算法的正确性而不是数据的正确性。它对开发人员而不是用户有价值。一旦对解决方案有足够的信心,就可以禁用断言,程序仍然可以正常工作,用户不必运行带有额外运行时开销的程序。

扫码关注云+社区

领取腾讯云代金券