为什么断言是从生产版本（性能除外）中编译出来的？
从生产代码中删除断言的典型论据是性能。这对我来说没有意义。是的，从性能关键的 5% 左右的代码中剥离一些断言可能是一种有用的优化。然而，对于另外 95% 的人来说，它们可能没有可测量的效果，并且断言只会增加这样的可能性：如果您的代码有错误，它会以一种易于诊断的方式快速失败。
我的大部分编程都是在 D 中完成的，它有一个 enforce() 函数，它的作用基本上与 assert() 的作用相同，只是它保留在发布版本中。我通常发现自己大部分时间都在使用 enforce()，而 assert() 仅在少数地方使用 enforce()昂贵的。
除了性能之外，还有其他原因从发布版本中删除断言吗？如果不是，为什么语言不让断言的默认行为即使在发布版本中也始终执行，并提供第二个更冗长且更难记住的函数，例如被剥离的 expenseAssert()超出发布版本并建议仅在代码的性能关键部分使用它？
The typical argument for removing assertions from production code is performance. This doesn't make sense to me. Yes, stripping a few assertions out of the performance-critical 5% or so of your code can be a useful optimization. For the other 95%, though, they probably have no measurable effect, and asserts can only increase the likelihood that, if your code has a bug, it will fail fast and in an easy to diagnose way.
I do most of my programming in D, which has an enforce() function that does basically what assert() does except that it stays in release builds. I typically find myself using enforce() most of the time, and assert() only in a few places where enforce() would be too expensive.
Is there any other reason besides performance to remove asserts from release builds? If not, why don't languages make the default behavior of asserts to always execute even in release builds, and provide a second function that's more verbose and harder to remember, something like expensiveAssert() that is stripped out of release builds and recommend its use only in performance-critical parts of your code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为
assert()最初是作为一个纯粹的开发人员工具。面向最终用户的软件应该提供某种错误处理（通过记录和/或向用户显示消息）。
assert()不提供错误处理。但是，我通常使用自己的发布和调试断言函数。发布和调试断言都只用于异常错误——这种错误永远不应该发生。但它们给出了有用的错误消息（对开发人员有用，通常对最终用户没有多大帮助）。
可能发生的错误（输入/输出、错误配置等）会被显式处理并向用户提供消息。
I think
assert()was meant as a pure developers tool in the first place.A piece of software for end-users should provide some kind error handling (by logging and/or displaying a message to the user).
assert()does not provide error handling.However, I typically use my own release and debug assert functions. Both release and debug assert are only used for unusual errors - which should never occur. But they give a useful error message (useful for the developer, usually not so helpful for the end-user).
Errors that may occur (input/output, mis-configuration, ..) are explicitly handled and give a message to the user.
不仅如此。我认为在生产版本中保留断言会增加人们对什么文本（和/或源代码片段）最终出现在已发布的二进制文件中的偏执（想想如果它们最终出现在已发布的二进制文件中，代码注释会是什么样子！），这反过来又会导致不鼓励使用断言。
您的里程可能会有所不同。
It's not just that. I think having asserts kept in production builds would add to people's paranoia about what text (and/or source snippets) ends up in shipped binaries (think what code comments would be like if they ended up in shipped binaries!), which in turn would discourage use of assertions.
Your mileage may vary.
我的答案是断言会过早地中止程序的执行，通常是在没有必要的情况下。尽管人们可能会因为跳过断言导致不确定的行为而变得偏执，但程序无论如何都可能一瘸一拐地前进。当您作为用户遇到断言时，断言可能真的很烦人和愚蠢。比如，为什么这个游戏不能处理一个无效的纹理？！！
尽管断言是开发时快速捕获错误的好方法，但用户讨厌它们（在我看来）。
My answer would be that assertions prematurely abort execution of the program, often when it is not necessary. Although one might be paranoid because a skipped assertion results in undetermined behavior, the program may be able to limp along anyway. Assertions can be really annoying and stupid when you run into them as a user. As in, why can't this game deal with ONE invalid texture?!!
Although assertions are a great way to catch errors quickly when developing, users hate them (in my opinion).
我认为在生产代码中使用断言是可以的。禁用它会让您失去对生产系统中问题的一些见解。我总是对我的程序/系统在生产中的行为+失败感兴趣。在我看来，改进系统的最佳“测试数据”通常来自真实用户。
我更喜欢的是：
i think having assertions in production code is OK. disabling it makes you lose some insights about problems in your system in production. and i am always interested how my program/system behaves+fails in production. in my view the best "test-data" to improve your system often comes through real users.
what i prefer: