如果断言失败，是否有错误？

Question

我一直遵循逻辑：如果断言失败，那么就有一个错误。根本原因可能是：

• 断言本身无效（错误）
• 编程错误（错误）
• （没有其他选择）

即。可以得出任何其他结论吗？是否存在断言失败并且没有错误的情况？

Answer 1

如果assert失败，则调用者或被调用者都会出现错误。为什么会有一个断言？

Answer 2

是的，代码中存在错误。

Code Complete

  

断言检查条件   永远不应该发生。 [...]

     

如果是   断言因异常而被解雇   条件，纠正措施是   不仅仅是处理错误   优雅 - 纠正措施是   更改程序的源代码，   重新编译，并发布新版本   的软件。

     

一个好方法   认为断言是可执行的   文档 - 你不能依赖它们   使代码工作，但他们可以   更积极地记录假设   程序语言评论可以。

Answer 3

这是一个很好的问题。

我的感觉是，如果断言由于你的代码而失败，那么这就是一个bug。断言是代码的预期行为/结果，因此断言失败将导致代码失败。

Answer 4

仅当断言意图显示警告条件时 - 在这种情况下应该使用特殊类别的断言。

因此，任何断言都应该显示您建议的错误。

Answer 5

如果您使用断言，则遵循Bertrand Meyer's Design by Contract哲学。这是一个编程错误 - 您指定的合同（断言）没有被客户端（调用者）遵循。

Answer 6

如果您想在逻辑上包容所有可能性，请记住已知电子电路受到来自太空的辐射的影响。如果正确的光子/粒子恰好在正确的时间点击到正确的位置，它可能会导致逻辑上不可能的状态转换。

概率很小但仍然不为零。

Answer 7

我可以想到一个不会真正归类为错误的案例：

用于检查通常应该在那里的外部东西的断言。你正在寻找一台机器上发生的坚果，你想知道某个因素是否有责任。

一个真实世界的例子（虽然从断言时代开始）：如果某个目录被隐藏在某个机器上，那么程序就会被禁止。如果目录被隐藏，我从未发现任何应该关心的代码片段。我只能非常有限地访问有问题的机器（它上面有一堆会计内容）所以我无法在机器上正确地搜索它，我无法在其他地方重现它。使用该机器完成的任务（罪魁祸首从未被识别出来）偶尔会隐藏该目录。

我最终在启动时使用了一个测试，看看该目录是否被隐藏，如果错误就停止了。

Answer 8

没有。断言失败意味着原始程序员不打算或预期会发生的事情。

这可以表明：

• 代码中的错误（您只是错误地调用方法）

• 断言中的一个错误（原始程序员过于热心，并抱怨你做了一些非常合理的事情，而且这个方法实际上处理得非常好。

• 被调用代码中的错误（设计缺陷）。也就是说，被调用代码提供的合同不允许您执行您需要执行的操作。断言警告你，你不能这样做，但解决方案是扩展被调用的方法来处理你的输入。

• 一个已知但未实现的功能。想象一下，我实现了一个可以处理正整数和负整数的方法，但我只需要它（现在）来处理正整数。我知道“完美”实现会同时处理两者，但是直到我实际上需要它来处理否定，实现支持是浪费精力（它会增加代码膨胀并可能减慢我的速度）应用）。所以我考虑了这个案例，但在决定需要之前我决定不实施它。因此，我添加一个断言来标记这个未实现的代码。当我稍后通过传递负值来触发断言时，我知道现在需要额外的功能，所以我必须扩充实现。推迟编写代码直到实际需要它因此节省了我很多时间（在大多数情况下我从不补充附加功能），但是当我尝试使用未实现的功能时，断言确保我没有得到任何错误。