异常与断言？

Question

  

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

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

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

Answer 1

我的经验法则：

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

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

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

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

Answer 2

断言你知道的东西不会发生（即如果它发生了，那就是你不称职的错误）。

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

Answer 3

您使用例外情况的例外情况。例如，内存不足或网络故障。

您使用assert 确定满足cetain前提条件。例如，指针不是NULL或整数在特定范围内。

Answer 4

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

Answer 5

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

我为其他一切使用例外。

在可重用代码中，我更喜欢异常，因为它为调用者提供了处理或不处理问题的选择。试着捕捉并处理一个断言！

Answer 6

作为一般规则，我抛出以下异常：

1. 程序包的公共函数以捕获编程错误。
2. 报告系统错误或传递子系统错误的内部函数。

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