assert - 断言什么时候应该留在生产代码中？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

2年前关闭。




Improve this question




有一个discussion继续在 comp.lang.c++.moderate 关于断言(在 C++ 中默认情况下仅存在于调试版本中)是否应该保留在生产代码中。

显然，每个项目都是独一无二的，所以我的问题是不是 这么多是否应该保留断言，但在哪些情况下这是值得推荐的/不是一个好主意。

通过断言，我的意思是:

一种运行时检查，用于测试一个条件，当该条件为假时，会显示软件中的错误。

程序停止的一种机制(可能在非常少的清理工作之后)。

我不一定在谈论 C 或 C++。

我自己的观点是，如果你是程序员，但不拥有数据(大多数商业桌面应用程序就是这种情况)，你应该继续使用它们，因为失败的断言表明存在错误，你不应该去有一个错误，有损坏用户数据的风险。这迫使您在发布之前进行严格的测试，并使错误更加明显，从而更容易发现和修复。

你的意见/经验是什么？

干杯，

卡尔

查看相关问题 here

回复和更新

嘿，格雷厄姆，

An assertion is error, pure and simple and therefore should be handled like one. Since an error should be handled in release mode then you don't really need assertions.

这就是为什么我在谈论断言时更喜欢“bug”这个词。它使事情变得更加清晰。对我来说，“错误”这个词太模糊了。丢失的文件是错误，而不是错误，程序应该处理它。试图取消引用空指针是一个错误，程序应该承认有些东西闻起来像坏奶酪。

因此，您应该使用断言测试指针，但使用正常的错误处理代码测试文件的存在。

稍微偏离主题，但在讨论中很重要。

提醒一下，如果您的断言在失败时闯入调试器，为什么不呢。但是文件无法存在的原因有很多，完全不受代码的控制:读/写权限、磁盘已满、USB 设备已拔出等。由于您无法控制它，我觉得断言是不是处理这个问题的正确方法。

卡尔

托马斯，

是的，我有 Code Complete，并且必须说我非常不同意那个特别的建议。

假设您的自定义内存分配器搞砸了，并将一 block 仍由其他对象使用的内存归零。我碰巧将这个对象定期取消引用的指针归零，其中一个不变量是这个指针永远不会为空，并且您有几个断言来确保它保持这种状态。如果指针突然为空怎么办。您只是 if() 围绕它，希望它有效吗？

请记住，我们在这里讨论的是产品代码，因此没有闯入调试器并检查本地状态。这是用户机器上的一个真正的错误。

卡尔

Answer 1

如果您甚至考虑在生产中保留断言，那么您可能认为它们是错误的。断言的全部意义在于您可以在生产中将其关闭，因为它们不是您解决方案的一部分。它们是一种开发工具，用于验证您的假设是否正确。但是当您投入生产时，您应该已经对您的假设充满信心。

也就是说，有一种情况我会在生产中打开断言:如果我们在生产中遇到一个在测试环境中很难重现的可重现错误，那么在打开断言的情况下重现错误可能会有所帮助在生产中，看看它们是否提供了有用的信息。

一个更有趣的问题是:在您的测试阶段，您什么时候关闭断言？