error-handling - 为什么断言是从生产构建中编译出来的(性能除外)？

Question

从生产代码中删除断言的典型论点是性能。这对我来说没有意义。是的，从性能关键的 5% 左右的代码中剥离一些断言可能是一种有用的优化。然而，对于其他 95%，它们可能没有可衡量的效果，断言只会增加可能性，如果您的代码有错误，它会以一种易于诊断的方式快速失败。

我的大部分编程都是用 D 语言完成的，它有一个 enforce()基本功能 assert()除了它保留在发布版本中。我通常发现自己在使用 enforce()大部分时间，以及 assert()仅在少数地方enforce()会太贵。

除了性能之外，还有其他原因可以从发布版本中删除断言吗？如果不是，为什么语言不使断言的默认行为即使在发布版本中也始终执行，并提供更冗长且难以记住的第二个函数，例如 expensiveAssert()从发布版本中剥离出来并建议仅在代码的性能关键部分使用它？

Answer 1

我想 assert()首先是作为纯粹的开发人员工具。

面向最终用户的软件应该提供某种错误处理(通过记录和/或向用户显示消息)。 assert()不提供错误处理。

但是，我通常使用自己的发布和调试断言函数。 release 和 debug assert 都只用于异常错误 - 这应该永远不会发生。但是它们给出了有用的错误消息(对开发人员有用，通常对最终用户没有太大帮助)。

可能发生的错误(输入/输出、错误配置等)被明确处理并向用户提供消息。