很多时候，你会有一个函数，对于给定的参数无法生成有效的结果或者无法执行某些任务。除了异常，在C/C++世界中不太常用之外，基本上有两种报告无效结果的方法。
第一种方法是将有效返回值与不属于函数值域的值（通常为-1）混合在一起，并指示出错。
int foo(int arg) {
if (everything fine)
return some_value;
return -1; //on failure
}
bool foo(int arg, int & result) {
if (everything fine) {
result = some_value;
return true;
}
return false; //on failure
}
不要忽略异常，因为它们代表的是非常罕见且意外的错误。
然而，仅仅回答你的问题，这个问题最终是主观的。关键问题是考虑哪种方式对你的消费者来说更容易使用，同时悄悄地提示他们记得检查错误条件。在我看来，这几乎总是"返回一个状态码，并将值放在单独的引用中"，但这完全是一个人的个人观点。我提供的理由是...
返回混合错误代码/值模型的论据可能是简单性--没有额外的变量浮动，这是其中之一。但对我来说，危险比有限的收益更糟糕-很容易忘记检查错误代码。这是使用异常的一个论据-如果没有处理它们，你的程序将会崩溃。
CreateFile在失败时返回一个NULL句柄，其中NULL始终被理解为无效。当没有这样的概念时，例如atoi在失败时返回0，这就不太好了。 - Steven SuditCreateFile在失败时返回的是INVALID_HANDLE_VALUE(~0)而不是NULL(0)。通常情况下，NULL用于未初始化但未分配的句柄变量，而INVALID_HANDLE_VALUE用于表示失败。 - Ben Voigtdouble divide(double a, double b){
return a / b;
}
当 b 为 0 时应该怎么做：
boost::optional<double> divide(double a, double b){
if ( b != 0){
return a / b;
}else{
return boost::none;
}
}
请按照以下方式使用。
boost::optional<double> v = divide(a, b);
if(v){
// Note the dereference operator
cout << *v << endl;
}else{
cout << "divide by zero" << endl;
}
template <typename T>
T f( const T & t ) {
if ( SomeFunc( t ) ) {
return t;
}
else { // error path
return ???; // what can we return?
}
}
在这种情况下，我们没有明显的特殊值可以返回，所以抛出异常真的是唯一的方法。返回布尔类型需要检查，并通过引用传递真正有趣的值会导致可怕的编码风格。
许多书籍和文章都强烈建议使用第一种方式，这样你就不会混淆角色并强制返回值携带两个完全无关的信息。
虽然我同情这种观点，但实践中我发现第一种方法通常更好。显而易见的是，在第一种情况下，您可以将赋值链接到任意数量的接收者，但在第二种情况下，如果您需要/想要将结果分配给多个接收者，则必须进行调用，然后单独进行第二次赋值。即，
account1.rate = account2.rate = current_rate();
vs.:
set_current_rate(account1.rate);
account2.rate = account1.rate;
或者：
set_current_rate(account1.rate);
set_current_rate(account2.rate);
HANDLE的函数具有INVALID_HANDLE_VALUE，而IUknown::AddRef和IUnknown::Release不返回HRESULT。这也有一个很好的原因：这些API被用于调用各种语言编写的消费者。 - Ben VoigtHeapAlloc、CreateWindow、CreateDC和CreateIC。RegisterClass和RegisterClassEx返回一个ATOM，或者0表示失败。RegisterWindowMessage返回一个消息标识符，或者0表示失败。这个列表还可以继续下去... - Jerry Coffinerrno以指示错误。你错过了一个方法：返回失败指示并需要额外调用以获取错误的详细信息。
这个方法有很多值得称赞的地方。
例如：
int count;
if (!TryParse("12x3", &count))
DisplayError(GetLastError());
编辑
这个答案引起了相当多的争议和负评。坦白地说，我完全不被反对的论点所说服。将调用是否成功与失败原因分开已被证明是一个非常好的想法。将两者结合在一起会迫使你遵循以下模式：
HKEY key;
long errcode = RegOpenKey(HKEY_CLASSES_ROOT, NULL, &key);
if (errcode != ERROR_SUCCESS)
return DisplayError(errcode);
与此形成对比的是：
HKEY key;
if (!RegOpenKey(HKEY_CLASSES_ROOT, NULL, &key))
return DisplayError(GetLastError());
(GetLastError版本与Windows API的工作方式一致，但直接返回代码的版本是实际工作方式，因为注册表API不遵循该标准。)
无论如何，我建议错误返回模式使人们很容易忘记函数失败的原因，导致出现以下代码:
HKEY key;
if (RegOpenKey(HKEY_CLASSES_ROOT, NULL, &key) != ERROR_SUCCESS)
return DisplayGenericError();
编辑
看了 R. 的请求后，我找到了一个实际可以满足该请求的场景。
对于一个通用的 C 风格 API，例如在我的示例中使用的 Windows SDK 函数，没有非全局上下文可用来存储错误代码。因此，我们别无选择，只能使用一个全局的 TLV（类型-长度-值），以便在失败后进行检查。
但是，如果将范围扩展到类的方法，则情况就不同了。如果有一个变量 reg 是 RegistryKey 类的实例，那么调用 reg.Open 返回 false 就是完全合理的，这时需要调用 reg.ErrorCode 来检索详细信息。
我认为这样就满足了 R. 的关于错误代码作为上下文的要求，因为实例提供了上下文。如果我们不是调用 RegistryKey 实例，而是调用静态的 Open 方法，则在失败后检索错误代码也必须是静态的，这意味着它必须是一个 TLV，虽然不是完全全局的。类本身作为上下文。
HRESULT并将其存储在TLV中。该实例可以隐式转换为bool以进行错误检测。默认构造函数从TLV检索值。它还具有“DidFail”、“DidSuccess”和“ThrowOnFail”等方法。 - Steven Sudit这两者之间不应该有太大的性能差异，选择取决于具体的使用情况。如果没有适当的无效值，则不能使用第一个。
如果使用C ++，则除了这两种方法之外，还有许多其他可能性，包括异常和使用类似boost :: optional作为返回值。
C语言通常使用第一种方法在有效结果中编码魔术值，这就是为什么你会得到像strcmp()在匹配时返回false（= 0）这样有趣的东西。
许多标准库函数的新版本采用第二种方法- 明确返回状态。
并且在这里不适合使用异常。异常是用于代码可能无法处理的特殊情况 - 你不能因为strcmp()未匹配就引发异常。
strcmp在匹配时不会返回"false"。与任何比较函数一样，它返回一个正数、负数或零值，反映第一个项目是否大于、小于或等于给定排序中的第二个项目。这并没有什么神奇的地方，它是常识。你是否希望(a-b)（用于数字a和b的比较函数）在匹配时返回"true"，否则返回"false"？ - R.. GitHub STOP HELPING ICEstrcmp 的所有可能返回值都不表示错误，因此它既不是魔数的好例子，也不是异常使用的好例子。也许 fgetc（它返回魔数 EOF）会是一个更好的例子。 - Ben Voigtif (strcmp()==0) (pointer!=NULL) (number>0)。可悲的是，那些不阅读标准库函数定义的程序员也是那些不阅读有关良好和不良风格建议的人... ;) - Secure虽然不总是可能，但无论使用哪种错误报告方法，最佳实践是尽可能设计一个函数，使其没有失败情况，并在不可能的情况下最小化可能的错误条件。以下是一些示例：
不要通过许多函数调用深入传递文件名，而是设计程序，使调用者打开文件并传递FILE *或文件描述符。这消除了每个步骤中“无法打开文件”的检查并将其报告给调用者。
如果有一种廉价的方法来检查（或找到上限）函数将需要为其构建和返回的数据结构分配的内存量，请提供一个函数来返回该数量，并让调用者分配内存。在某些情况下，这可能允许调用者简单地使用堆栈，大大减少内存碎片化并避免malloc中的锁定。
当函数执行的任务需要大量工作空间时，请询问是否有具有O(1)空间要求的替代（可能更慢）算法。如果性能不关键，则只需使用O(1)空间算法。否则，实现回退案例以在分配失败时使用它。
这只是一些想法，但在整个应用相同的原则可以真正减少您需要处理并向上传播多个调用级别的错误条件的数量。
对于C ++，我倾向于使用模板解决方案，可以避免输出参数的"难看"和联合答案/返回代码中"魔术数字"的"难看"。 我在回答另一个问题时阐述了这一点。 请看一下。
对于C语言，我认为丑陋的输出参数比丑陋的"魔术数字"更容易接受。