可能的重复：
通过断言或异常进行合同测试设计？
在决定使用异常而不是断言（反之亦然）时，是否有一个经验法则可以遵循。现在我只会抛出我认为在用户端运行时会发生的事情（比如套接字或文件错误）。几乎我使用的所有其他东西都断言。
另外，如果我要抛出一个断言，那么抛出一个好的标准对象是什么？如果我没记错的话，有std::logic_error，但这不是扔的好东西吗？我会为丢失的文件或意外输入（例如从命令行而不是前端应用程序）抛出什么？
user34537
问问题
49411 次
6 回答
61
我的经验法则：
异常用于运行时错误情况（IO 错误、内存不足、无法获得数据库连接等）。
断言用于编码错误（此方法不接受空值，开发人员还是通过了一个）。
对于具有公共类的库，在公共方法上抛出异常（因为这样做很有意义）。断言是用来捕捉你的错误，而不是他们的。
编辑：由于空值示例，这可能并不完全清楚。我的观点是，您将断言（正如其他人指出的那样）用于永远不会发生的条件，用于永远不会进入生产代码的条件。这些条件在单元测试或 QA 测试期间绝对必须失败。
于 2009-01-03T22:12:49.707 回答
30
断言你知道不可能发生的事情（即如果它发生了，那是你不称职的错）。
提出程序的常规控制流未处理的异常情况。
于 2009-01-03T21:08:34.827 回答
4
我将断言用于那些不应该发生但确实发生的事情。当它发生时，开发人员需要重新审视不正确的假设。
我对其他一切都使用例外。
在可重用代码中，我更喜欢异常，因为它让调用者可以选择处理或不处理问题。试着捕捉和处理一个断言！
于 2009-01-03T22:03:08.743 回答
4
您在异常情况下使用异常。例如内存不足或网络故障。
您使用 assert 来确定满足某些前提条件。例如，指针不是 NULL 或整数在一定范围内。
于 2009-01-03T20:48:36.757 回答
2
断言是一种验证程序是否处于可能状态的方法。如果一个函数在应该只返回正整数时返回 -1，并且您有一个断言来验证这一点，那么您的程序应该停止，因为它使您的程序处于危险状态。
于 2009-01-03T20:49:57.593 回答
1
作为一般规则，我从以下位置抛出异常：
- 包的公共函数以捕获编程错误。
- 报告系统错误或传递子系统错误的内部函数。
我只在内部使用断言来捕获实现错误。
于 2009-01-03T21:37:14.817 回答