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