我的问题是从语言设计的角度提出的。
为什么assert被区别对待,比如它会引发错误而不是异常,默认情况下不会启用它等等。
它看起来确实优雅(非常主观的观点),易于阅读(同样是主观的)来做验证&还有一些工具(IDE)可以对其进行实时评估,并根据断言提供警告。
发布于 2015-03-18 19:50:50
我要说的原因是,Java的默认设置是针对产品代码(软件的“发布”版本)的-如果用户需要构建您的代码,他们将使用提供的默认设置,如果您是开发人员,并且想要有更好的报告,您总是可以做一些额外的努力。
通常,您不希望将断言与发布版本一起发布。为什么?你总是可以设计你的代码来执行一些不会干扰后台的错误处理,而在用户面前抛出AssertionError
并不总是正确的方法。
大多数时候,我看到它们被用作额外的代码测试--当你运行回归测试并且代码覆盖率很高时,没有断言错误表明你的代码中没有(明显的)错误。如果发生了某些情况,您可以从堆栈跟踪中推断出出了什么问题以及原因。另一方面,客户端不应该为查看描述性错误信息而烦恼。
那么,您应该如何实际使用它们呢?根据我的经验,您应该将代码设计为不使用断言来执行错误处理。如果您希望在某个地方抛出异常,请自己显式抛出它。一旦代码可以自己处理,你就可以添加断言来检查前置和后置条件以及不变量-所以基本上是用它们来检查算法的正确性,而不是数据的正确性。它对开发人员而不是用户有价值。一旦您对解决方案有了足够的信心,您就可以禁用断言,您的程序仍然可以正常运行,并且您的用户不必运行具有额外运行时开销的程序。
发布于 2018-09-23 01:46:21
断言是开发人员的工具。
默认情况下没有启用它的核心原因是,通过assert
的断言并不意味着要为生产代码提供运行时验证/保护。
assert
是在开发过程和测试过程中使用的工具,在生产环境中的实际运行过程中不应影响性能。
设想一个非常重要的断言,它在构建新功能或针对整个允许的输入范围进行更改时非常关键,但一旦构建并正确测试,就不需要运行,直到代码再次更改。
发布于 2015-03-18 19:42:24
它会引发错误,因为断言冲突的严重性足以做到这一点。
一个异常的例子是类似ArrayIndexOutOfBounds
的东西。这在某些情况下可能是合理的,您甚至可能期望(并处理)这样的情况。
但是断言冲突是(比如内存不足)没有你想要的或者你想要处理的东西。这是一个错误,没有任何借口。
断言在默认情况下是不启用的,因为它们应该始终是完全填充的。你使他们能够测试这一点,但是你“知道”(就你所能知道的)他们没有被违反。因此,您不需要在生产代码中每次都检查条件(这可能是性能密集型的)。
Java中断言的好处是,当没有启用断言时,实际执行检查的代码永远不会被执行。
例如:
if (!doComplexChecks()) throw new AssertionError("Damn!");
可能要花很多时间,你想在单元测试或调试时验证这一点,但在生产中,你不想这样做。
但是这段代码
assert doComplexChecks();
只有在启用了断言的情况下才会执行,因此它为您节省了大量的生产代码时间。
https://stackoverflow.com/questions/29120928
复制相似问题