在哪里放置断言？答案

【问题标题】：Where to put Assertions?在哪里放置断言？
【发布时间】：2011-01-31 07:17:25
【问题描述】：

对意外情况进行断言被认为是良好的防御性编码实践。每当我认为可能会发生意想不到的事情时，我碰巧会做出断言，但现在这对我来说似乎有点矫枉过正。

此外，有时不一定会导致崩溃的轻微意外情况甚至可能导致客户端出现故障。

是否有硬性规定来放置断言？

谢谢。

【问题讨论】：

【解决方案1】：

何时使用断言和异常的主要区别：

出于调试目的，您可以决定在引发异常的地方使用断言，以便能够更轻松地找出引发异常的地方，尽管您可以使用插入 FILE 和 LINE 也可以添加到消息中。

【讨论】：

【解决方案2】：

在哪里放置断言？

经常被忽视的是，断言也可以作为文档辅助。

因此，不仅要测试“意外”，还要使用它们在代码的关键点表达您的假设（不变量）。点赞assert(high >= low)

当然，正如其他人在这里指出的那样，使它们成为有条件的。

【讨论】：

【解决方案3】：

不，没有……但我绝对建议在测试和生产中以不同的方式处理断言。

在测试环境中生成核心转储是完全可以的。通过很好地保持程序的整个状态，它可以轻松检查触发断言的条件。

但是在生产环境中，您永远不想崩溃（除非内存损坏......）。用户期望系统始终响应，没有什么比请求某些东西而从未收到响应更令人恼火的了。因此，您的工作是确保用户获得可能更有意义的响应，即使它是一条错误消息。实现这一点的最简单方法通常是抛出异常。

【讨论】：

【解决方案4】：

当您非常确定在进入下一个代码级别之前必须满足某些条件时，就会放置断言。例如，当窗口句柄无效或某些变量没有有效值时。

【讨论】：

【解决方案5】：

从它的声音来看，您可以在发布版本中启用它们。如果是这样，创建断言级别 - 那些将在某些构建中启用或禁用的断言。然后只需使用断言级别。

这样，您无需在开发和调试版本或测试版中关闭、关闭或删除它们。

我通常会在发布时禁用它们，但它们确实会消耗大量的书面代码。我不认为这很糟糕 - 它用作文档并强制接口按预期使用。我认为拥有许多开发人员可能认为太多的断言是件好事，但总体上并没有太多断言，因为代码库会不断发展，这可以确保程序始终按预期使用。因此，我不建议删除它们，只需禁用发布版本的非致命检查即可。

最终，有比级别更好的方法（请参阅下面的讨论并从其他人的回答中获取您想要的） - 但级别是引入更改而不会对现有程序产生重大影响的一种简单方法。这将是过渡到另一个错误处理方案的好方法，或者如果您对已有的内容感到满意 > 98%。

【讨论】：

我曾经考虑过断言的级别，但是当测试中捕获的错误没有在生产中捕获时，这是非常令人惊讶的。此外，我发现开发者通常不知道适用于哪个级别，或多或少根据自己的心情选择......
@Matthieu 很重要的一点 - 在必要时使用指定的致命条件处理程序（和警报或日志消息）并禁用生产断言会更干净。当然，这取决于 OP 的致命错误条件的比率以及现有代码的实现方式。在可能的情况下，我的代码没有异常 - 错误代码/状态在检测到或遇到时只是推送给调用者。但是重写现有程序可能会很麻烦，因此我建议将级别作为一种不会对现有代码产生太大影响的解决方案。