异常与断言？ [复制]答案

【问题标题】：Exception vs Assert? [duplicate]异常与断言？ [复制]
【发布时间】：2010-09-29 09:59:17
【问题描述】：

可能重复：
design by contract tests by assert or by exception?

在决定使用异常而不是断言（反之亦然）时，是否有一个经验法则可以遵循。现在我只会抛出我认为在用户端运行时会发生的事情（比如套接字或文件错误）。我使用的几乎所有其他东西都断言。

另外，如果我要抛出一个断言，那么抛出一个好的标准对象是什么？如果我没记错的话有std::logic_error，但这不是扔的好东西吗？我会为丢失的文件或意外输入（例如从命令行而不是前端应用程序）抛出什么？

【问题讨论】：

【解决方案1】：

我的经验法则：

异常用于运行时错误情况（IO 错误、内存不足、无法获得数据库连接等）。

断言用于编码错误（此方法不接受空值，开发人员还是传递了一个）。

对于具有公共类的库，在公共方法上抛出异常（因为这样做很有意义）。断言是用来捕捉你的错误，而不是他们的。

编辑：由于空值示例，这可能并不完全清楚。我的观点是，您将断言（正如其他人指出的那样）用于永远不会发生的条件，用于永远不会进入生产代码的条件。在单元测试或 QA 测试期间，这些条件绝对必须失败。

【讨论】：

你能解释一下为什么公共图书馆方法应该抛出异常吗？我看不出人们怎么可能从非法参数或坏对象状态中恢复过来。
当然。如果您正在编写公共库方法，并且有人将非法参数传递给您，那么您会抛出。你无法从中恢复过来。据推测，有人正在使用您的图书馆。纠正缺陷是他们的工作。你是绝对正确的：你无法从中恢复。让你的来电者去做。
调用者如何恢复？如果开发人员错误地使用了我的库，这是一个编码错误，它既不能从生产中恢复，也不能出现在生产环境中。
但这就是重点。他通过在缺陷投入生产之前修复缺陷来恢复。
问题是从您编译的程序集的发布版本中删除了一个断言。如果您正在编译发布版本，则无法使用它。你必须扔掉。

【解决方案2】：

断言你知道不可能发生的事情（即，如果发生了，那是你不称职的错）。

提出程序常规控制流未处理的异常情况。

【讨论】：

【解决方案3】：

您在异常情况下使用例外。例如内存不足或网络故障。

您使用断言来确定满足某些前提条件。例如指针不为 NULL 或整数在一定范围内。

【讨论】：

“assert”和“ascertain”的并行性不起作用。 “断言”是肯定的声明，而“确定”是学习。因此，assert 以“真实”为前提，而“confirm”则表明没有特别的偏见。这不是一个糟糕的助记词，但建议的词源是有缺陷的。
同意Argalatyr。断言是“坚持”、“大胆地宣布”或类似的意思。确定是“确定地发现，如通过检查或实验”，其中“发现”是同义词。
此外，“例外情况的例外”规则可以使用澄清。为什么网络故障异常但不是空指针？

【解决方案4】：

我对不应该发生的事情使用断言。当这种情况发生时，开发人员需要重新审视不正确的假设。

我对其他一切都使用例外。

在可重用代码中，我更喜欢异常，因为它让调用者可以选择处理或不处理问题。只需尝试捕获和处理断言！

【讨论】：

【解决方案5】：

断言是一种验证程序是否处于可能状态的方法。如果一个函数在应该只返回正整数时返回 -1，并且您有一个断言来验证这一点，那么您的程序应该停止，因为它会使您的程序处于危险状态。

【讨论】：

奇怪的是，在关于异常与断言的 Q 中，您根本没有提到前者。但是关于你所说的断言：什么是“可能的状态”？由于断言仅在调试模式下运行，因此它们只能在开发中用于捕获不应该编写的错误。一旦一个程序在野外，它应该没有错误（绝望的乌托邦，我知道，但幽默我）并且可以在发布模式下运行，所以断言不会捕获任何东西。但是错误可能来自用户做古怪的事情，包括我们从未认为“可能”的输入排列......因此需要例外

【解决方案6】：

作为一般规则，我会从以下位置抛出异常：

我只在内部使用断言来捕获实现错误。

【讨论】：