为什么我们在从 main() 返回时遵循相反的约定？答案

【问题标题】：Why do we follow opposite conventions while returning from main()?为什么我们在从 main() 返回时遵循相反的约定？
【发布时间】：2010-03-03 15:08:34
【问题描述】：

我经历过this和this，

但我在这里要问的问题是为什么0 被认为是Success？

我们总是将0 与false 联系起来，不是吗？

【问题讨论】：

真/假和成功/失败之间有什么关系？我看不出有任何隐含的理由将它们联系起来。如果你问“这个函数是否成功”，那么当然有一个关联，但是 C 中任何类型的返回代码都没有隐含的含义。

【解决方案1】：

因为失败案例多于成功案例。

通常，我们成功只有一个原因（因为我们成功:)），但我们可能失败的原因有很多。所以0代表成功，其他都代表失败，可以用值来报告原因。

对于代码中的函数，这是不同的，因为您是指定接口的人，因此可以使用 bool 如果足够的话。对于main，有一个固定的返回接口，可能有程序只报告成功/失败，但其他需要更精细的错误报告。为了满足所有这些，我们将有多个错误案例。

【讨论】：

+1 确实，当一切正常时，细节并不有趣。但是当我们收到错误时，您想知道原因。
这没有回答为什么相同的逻辑不适用于 C/C++/etc 真值表。为什么他们将错误代码放在 errno 而不是返回代码中仍然是个谜？现在修复它为时已晚。
@jmucchiello，是的，我也想知道。 0 表示 true 和 non-0 false 会很好，我想。也许它在这里不太重要，因为在布尔上下文中，无论如何只有两个答案（真和假），因此无法区分多个错误情况，并且对于其他所有情况，都使用switch。对地址为0x0 的空指针的有效处理可能也是这里的一个问题。但是，让0 到true 的隐式转换有意义并且同步真值表仍然会有好处。
就个人而言，出于同样的原因，我也会使用非零值作为内部 API 的故障指示器。然后，而不是问“我成功了吗”？我问“我失败了吗”？当涉及到错误代码时，True/False 没有语义意义。

【解决方案2】：

我不得不对 Johannes 的回答提出一点质疑。真 0 用于成功，因为只有 1 个成功的结果，而可能有许多不成功的结果。但我的经验是，返回代码与失败的原因的关系比失败的级别关系要小。

在批处理编程的日子里，通常有返回代码的约定，允许对整个执行流进行某种程度的自动化。所以返回码 4 可能是一个警告，但下一个工作可以继续； 8 可能意味着作业流应该停止； 12 可能意味着发生了灾难性事件，应该通知消防部门。

同样，批次会留出一定范围的返回码，以便整个批次流可以分支。例如，如果更新程序返回 XX，批处理可能会跳过备份步骤，因为没有任何变化。

作为失败原因的返回代码并没有那么有用，肯定不如日志文件、核心转储、控制台警报等等。例如，我从未见过一个系统返回 XX，因为“找不到这样的文件”。

【讨论】：

C 并且返回值的约定是在“批处理文件”和“错误级别”成为比尔盖茨的 ....microsoft 之前设计的。 :-)
@R - 我想到的主要模型是 IBM 大型机批处理，其中将提交作业流，作业控制语言将对返回代码做出反应。他们是（几乎）在比尔盖茨对他的父亲发痒之前的一次会议......

【解决方案3】：

通常，任何给定程序的返回值往往是可能值的列表（枚举），例如Success 或特定错误。作为一个“列表”，这个列表通常倾向于从 0 开始并向上计数。（顺便说一句，这也是 Microsoft 错误代码 0 为 ERROR_SUCCESS 的部分原因。

在全球范围内，Success 往往是几乎所有程序都应该能够返回的唯一返回值之一。即使一个程序有几个不同的错误值，Success 也往往是一个共同的必需品，因此在返回值列表中被赋予最常见的位置。

这只是默认情况下允许最常见的返回值的最简单方法。它与boolean 的想法完全不同。

【讨论】：

【解决方案4】：

这是我习惯于不同公司的惯例（尽管这显然因地而异）：

【讨论】：

【解决方案5】：

当我第一次开始编程时，我也觉得这很令人困惑。我在心里解决了这个问题，0 表示没有问题。

【讨论】：