断言何时应保留在生产代码中? [英] When should assertions stay in production code?

问题描述

有一个讨论在comp.lang.c ++上进行.对是否应在生产代码中保留断言(断言在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.

通过断言，我的意思是:

By assertion, I mean:

• 运行时检查，用于测试条件，如果条件为false，则表明该软件存在错误.
• 一种暂停程序的机制(也许是在清理工作很少之后).

我不一定要谈论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.

您的看法/经验是什么?

What's your opinion/experience?

干杯

卡尔

在这里

响应和更新

嘿，格雷厄姆，

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

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"一词的原因.这使事情变得更加清晰.对我来说，错误"一词太含糊了.丢失的文件是错误，而不是错误，程序应对其进行处理.尝试解除对空指针的引用是一个错误，程序应该承认有些东西闻起来像不好的奶酪.

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.

卡尔

托马斯

是的，我有完整的代码，必须说我完全不同意该特定建议.

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屋！