断言何时应保留在生产代码中？

Question

在comp.lang.c ++。moderated上有一个讨论，讨论是否应将断言（应在C ++中默认情况下仅存在于调试版本中）保留在生产代码中。显然，每个项目都是独特的，所以在这里我的问题是没有这么多是否断言应该保持，但在这情况下，这是值得推荐的/不是一个好主意。断言是指：一种运行时检查，用于测试条件，如果条件为false，则表明该软件存在错误。暂停程序的一种机制（可能是在清理工作最少之后）。我不一定要谈论C或C ++。我个人的意见是，如果您是程序员，但不拥有数据（大多数商业桌面应用程序就是这种情况），则应保留它们，因为断言失败会显示错误，并且您不应该去带有错误，可能会损坏用户的数据。这迫使您在发货之前进行严格的测试，并使错误更明显，从而更容易发现和修复。您的看法/经验是什么？干杯，卡尔在这里查看相关问题回应和更新嘿，格雷厄姆，断言是错误，纯净而简单的断言，因此应像对待一个断言一样处理。由于应该在发布模式下处理错误，因此您实际上不需要断言。这就是为什么我在谈论断言时更喜欢“ bug”一词的原因。它使事情变得更加清晰。对我来说，“错误”一词太含糊。丢失的文件是错误，而不是错误，程序应处理该文件。尝试取消引用空指针是一个错误，程序应该承认有些东西闻起来像不好的奶酪。因此，您应该使用断言测试指针，但是使用正常的错误处理代码来测试文件的存在。话题不大，但在讨论中很重要。请注意，如果断言失败时您的断言进入调试器，为什么不这样做。但是有很多原因导致文件不存在，这完全超出了代码的控制范围：读/写权限，磁盘已满，USB设备拔出等。由于您无法控制它，因此我认为是断言不是正确的处理方式。卡尔托马斯是的，我有完整的代码，必须说我完全不同意该建议。假设您的自定义内存分配器已拧紧，并将零块仍由其他对象使用的内存清零。我碰巧将一个该对象定期取消引用的指针归零，其中一个不变因素是该指针永远不会为null，并且您有几个断言来确保它保持这种状态。如果指针突然为空，该怎么办。您只是围绕它if（），希望它能正常工作？记住，我们在这里谈论产品代码，因此不会破坏调试器并检查本地状态。这是用户计算机上的实际错误。卡尔

Answer 1

断言是不会过时的注释。他们记录了预期的理论状态，以及不应发生的状态。如果更改了代码，从而声明允许更改，则开发人员将很快得到通知，并需要更新断言。

Answer 2

请允许我引用史蒂夫·麦康奈尔的《代码完成》。关于断言的部分是8.2。

通常，您不希望用户在生产代码中看到断言消息。断言主要用于开发和维护期间。断言通常在开发时编译到代码中，并从代码中编译出来用于生产。

但是，在同一部分的后面，提供了以下建议：

对于高度健壮的代码，请断言然后再处理错误。

我认为，只要性能不是问题，就保留断言，而不是显示消息，而是将其写入日志文件。我认为建议也包含在“代码完成”中，但是我现在找不到。

Answer 3

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

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

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