Question

例如，我有一个接受一些参数的方法，比如

method1（int i)

参数int应为1或2

我可以使用assert (i == 1 || i ==2)

或抛出异常if (!(i==1) || (i==2)) throw std::exception

哪一个更好。我总是对assert vs explicit throw感到困惑。

Answer 1

这实际上取决于具体情况。

有四个主要的错误处理组：

断言 - 用于处理编程错误（“我们不希望这个函数得到一个NULL指针，如果确实如此，那是因为我们代码的其他部分被破坏了，它应该永远不会发生“）。如果断言不在那里，代码可能会崩溃，永远循环，或者“失败”。
例外 - 例如std::invalid_argument - 当程序EXPECTS出错时，会更多地使用它，并且有一些方法可以“再试一次”。当实际用户错误地使用该程序时更有可能 - 例如来自键盘/文件等的输入。如名称所示，这应该是一个“例外” - 一些不寻常和意外的事情。
返回值 - 当一个错误完全可能时（试图查看串口是否在COM1，COM2，COM3或COM4端口或“是否与我期望的方程匹配的结果？”）< / p>
让它崩溃 - 如果输入错误，应用程序耗尽内存等，就会崩溃。这看起来似乎是一种粗略的方法，但有时候你无论如何也无法做得更好 - 如果某些链表被破坏并且next节点没有指向，那么你在编译器中间实际上会做什么呢？您的特殊sentry指针，但NULL？打印消息可能会好一些，但数量不多。

Answer 2

传递给method1的整数是否总是由程序员完成，或者可能由应用程序的用户传入？

<强>断言下，例如，如果您的代码如下所示：

int i;
if ( condition ) {
    i = 1;
}
else {
    i = 3;
}

method1(i);

如果是这种情况，您可能希望使用assert，因为它表明您（程序员）发生了错误。如果i = 3，您希望程序爆炸并显而易见，代码中存在问题，因此您可以在将其发布给客户之前将其捕获。

抛出异常，另一方面，如果您的代码如下所示：

int i;
cin >> i;
method1(i);

您将用户的输入传递给该功能。你无法预料他们可能会进入什么。因此，如果它是无效值，您应该抛出异常或返回错误代码并相应地处理它（例如，向用户打印一条消息，说明他们输入了无效的数字）。

Answer 3

通常在调试版本中检查断言，但不检查发布版本。如果您想节省时间并跳过检查最终发布的代码，那么断言是可行的方法。如果即使在发布时你的功能需要面对意外的输入而爆炸，那么可能是例外。

当然，您对错误条件应该做的具体细节将根据您的示例中提供的内容而有所不同。