断言什么时候应该留在生产代码中? [英] When should assertions stay in production code?

问题描述

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

There's a discussion going on over at comp.lang.c++.moderated about whether or not assertions, which in C++ only exist in debug builds by default, should be kept in production code or not.

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

Obviously, each project is unique, so my question here is not so much whether assertions should be kept, but in which cases this is recommendable/not a good idea.

断言，我的意思是:

• 用于测试条件的运行时检查，如果该条件为假，则揭示软件中的错误.
• 停止程序的机制(可能是在真正完成最少的清理工作之后).

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

I'm not necessarily talking about C or C++.

我自己的观点是，如果您是程序员，但不拥有数据(大多数商业桌面应用程序就是这种情况)，您应该保留它们，因为失败的断言表明存在错误，而您不应该继续出现错误，否则可能会损坏用户的数据.这迫使您在发布前进行强有力的测试，并使错误更加明显，从而更容易发现和修复.

My own opinion is that if you're the programmer, but don't own the data (which is the case with most commercial desktop applications), you should keep them on, because a failing asssertion shows a bug, and you should not go on with a bug, with the risk of corrupting the user's data. This forces you to test strongly before you ship, and makes bugs more visible, thus easier to spot and fix.

您有什么看法/经验?

干杯，

卡尔

查看相关问题这里

回复和更新

格雷厄姆，

断言是错误的，纯粹而简单的，因此应该像断言一样处理.由于错误应在发布模式下处理，因此您实际上不需要断言.

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.

这就是我在谈论断言时更喜欢错误"这个词的原因.它使事情变得更加清晰.对我来说，错误"这个词太含糊了.丢失的文件是一个错误，而不是一个错误，程序应该处理它.尝试取消引用空指针是一个错误，程序应该承认某些东西闻起来像坏奶酪.

That's why I prefer the word "bug" when talking about assertions. It makes things much clearer. To me, the word "error" is too vague. A missing file is an error, not a bug, and the program should deal with it. Trying to dereference a null pointer is a bug, and the program should acknowledge that something smells like bad cheese.

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

Hence, you should test the pointer with an assertion, but the presence of the file with normal error-handling code.

有点跑题，但在讨论中很重要.

Slight off-topic, but an important point in the discussion.

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

As a heads-up, if your assertions break into the debugger when they fail, why not. But there are plenty of reasons a file could not exist that are completely outside of the control of your code: read/write rights, disk full, USB device unplugged, etc. Since you don't have control over it, I feel assertions are not the right way to deal with that.

卡尔

托马斯

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

Yes, I have Code Complete, and must say I strongly disagree with that particular advice.

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

Say your custom memory allocator screws up, and zeroes a chunk of memory that is still used by some other object. I happens to zero a pointer that this object dereferences regularly, and one of the invariants is that this pointer is never null, and you have a couple of assertions to make sure it stays that way. What do you do if the pointer suddenly is null. You just if() around it, hoping that it works?

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

Remember, we're talking about product code here, so there's no breaking into the debugger and inspecting the local state. This is a real bug on the user's machine.

卡尔

推荐答案

断言是不会过时的注释.它们记录了哪些理论状态是预期的，哪些状态不应该发生.如果代码发生更改，状态允许更改，开发人员很快就会收到通知并需要更新断言.

Assertions are comments that do not become outdated. They document which theoretical states are intended, and which states should not occur. If code is changed so states allowed change, the developer is soon informed and needs to update the assertion.

这篇关于断言什么时候应该留在生产代码中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！