应用程序应支持哪些“标准”应用程序返回/退出代码？答案

【问题标题】：What "standard" application return/exit codes should an application support?应用程序应支持哪些“标准”应用程序返回/退出代码？
【发布时间】：2009-10-08 16:18:14
【问题描述】：

是否有一套标准的应用程序返回码？诸如返回 0 表示成功 1 表示失败，然后以此类推？

我有一个 Windows Server 应用程序，我正在添加一些返回错误代码，除了我需要的应用程序特定代码之外，我还希望坚持使用标准代码。

【问题讨论】：

标签： windows standards

【解决方案1】：

我认为唯一的标准是 0 表示成功，非 0 表示失败。这更像是一种约定，而不是一种标准。

【讨论】：

【解决方案2】：

也许您可以采用一些 Unix 约定。

在another answer，用户大卫建议

sysexits.h 有一个标准退出代码列表。它似乎至少可以追溯到 1993 年，一些像 Postfix 这样的大项目使用它，所以我想这是要走的路。

来自 OpenBSD 手册页：

根据 style(9)，在结束程序时使用任意值调用 exit(3) 来指示失败情况并不是一个好习惯。相反，应该使用来自 sysexits 的预定义退出代码，因此进程的调用者可以在不查找源代码的情况下粗略估计故障类别。

这是显示在 Debian 系统上的列表：

#define EX_USAGE        64      /* command line usage error */
#define EX_DATAERR      65      /* data format error */
#define EX_NOINPUT      66      /* cannot open input */    
#define EX_NOUSER       67      /* addressee unknown */    
#define EX_NOHOST       68      /* host name unknown */
#define EX_UNAVAILABLE  69      /* service unavailable */
#define EX_SOFTWARE     70      /* internal software error */
#define EX_OSERR        71      /* system error (e.g., can't fork) */
#define EX_OSFILE       72      /* critical OS file missing */
#define EX_CANTCREAT    73      /* can't create (user) output file */
#define EX_IOERR        74      /* input/output error */
#define EX_TEMPFAIL     75      /* temp failure; user is invited to retry */
#define EX_PROTOCOL     76      /* remote error in protocol */
#define EX_NOPERM       77      /* permission denied */
#define EX_CONFIG       78      /* configuration error */

在文件/usr/include/sysexits.h 中可以找到这些错误代码的更详细描述。

【讨论】：

这是我用的。

【解决方案3】：

标准状态码是EXIT_SUCCESS和EXIT_FAILURE，定义在stdlib.h中。不过，几乎每个人都分别使用 0 和 1。有些软件会针对不同类型的错误使用不同的非零代码。

【讨论】：

【解决方案4】：

没有应用程序应该遵守的标准退出代码集。

但是，正如您提到的，有一些常见的值，例如 0 表示成功。根据您使用的操作系统和工具，您或许可以查看类似应用的退出代码并模仿它们。

【讨论】：

@Lurkers：尽管这是一个 Windows 问题，但我发现重要的是要指出，虽然没有硬标准（例如 ISO 或 DIN），但某些操作系统确实存在约定。例如，这里是 Linux 的标准退出代码：tldp.org/LDP/abs/html/exitcodes.html

【解决方案5】：

唯一真正的约定是0 表示成功，非零值（通常为1）表示失败。有关这方面的官方参考，例如，请参阅exit 上的 Microsoft C++ 文档：

通常，调用者将 status 值设置为 0 表示正常退出，或设置为其他值表示错误。

或者 Envrionment.Exit 和 Environment.ExitCode 上的 C# 文档有不同的状态：

使用 0（零）表示过程成功完成。

和

默认值为0（零），表示进程成功完成。

和

使用非零数字表示错误。在您的应用程序中，您可以在枚举中定义自己的错误代码，并根据场景返回相应的错误代码。例如，返回值 1 表示所需文件不存在，返回值 2 表示文件格式错误。有关 Windows 操作系统使用的退出代码列表，请参阅 Windows 文档中的 System Error Codes。

与some other answerers 不同，我强烈建议不要将系统错误代码用作应用程序退出代码。关于系统错误代码的一些说明：

Microsoft 不建议将它们用作应用程序退出代码任何地方，并且确实明确建议您在文档中“定义自己的错误代码”上面引用。
Microsoft 不会始终将它们用作其自己的 应用程序或命令中的退出代码。虽然有一些确实使用这些代码的应用程序示例，例如MsiExec.exe，但还有很多不使用这些代码的示例，例如dir、dotnet 或TAEF。李>
在我看来，使用它们显然是个坏主意。有 数以千计的 系统退出代码，其中大部分与您的特定应用程序无关。如果您尝试使用它们，您将浪费时间从列表中挑选适用于您的场景的代码，并且最终结果对于调用您的应用程序的开发人员来说将不如您刚刚定义一个小数字有用对您的特定应用有意义的退出代码 - 请改为这样做。

【讨论】：

或者只是挑选一些有用的，并将它们定义为您自己的错误代码，这些错误代码恰好会重复使用系统错误代码。只要您的程序具有可预测的行为，就没有人真正关心实现。

【解决方案6】：

退出代码远非标准，更多地用于开发人员了解应用程序返回时发生的相应错误。 0 表示成功，非 0 表示失败的标准是大势所趋，使用它是因为它允许您对所有可能的错误使用完整的非零范围。

如果您的应用程序正确记录错误，退出代码可能完全不需要跟踪。

【讨论】：

【解决方案7】：

肯定有为 Windows 定义的标准错误代码。

很久以前，我们对特定的“自定义”错误使用负错误，但我怀疑这是一种好的做法。

System Error Codes (Windows)

【讨论】：

您不必使用系统错误代码作为程序退出代码。正如此处其他答案所述，Windows 程序通常使用 1 作为包罗万象的错误代码；如果每个人都在使用系统错误代码，那总是意味着“功能不正确”（而且根本没有办法指出通用的未指定错误）。
是的，你不需要遵守标准。问题是关于标准的，这就是我提供的。基本情况为零表示成功，非零表示失败。如果调用者无法处理特定的失败，那么无论如何您都不会关心错误是什么，但是如果您希望调用者对失败采取行动，那么给出有意义的错误是一种很好的做法。标准有助于在这种情况下提供结构。
“你不需要遵守标准” - 这是不合逻辑的；使用系统错误代码作为应用程序退出代码对“符合标准”没有任何帮助，因为在任何地方都没有建议这样做的标准。 “如果您希望调用者处理失败，最好给出有意义的错误” - 我同意，但使用系统错误代码很难实现这一点，因为它们有数千个（所以调用者可以'不可能全部考虑）并且它们可能过于笼统而无法以有意义的方式描述特定于应用程序的错误。
系统错误代码 != 退出代码
Henrik 完全正确，系统错误代码！= 退出代码。但是，Microsoft 也在 application 代码示例中使用这些值。 docs.microsoft.com/en-us/dotnet/api/system.environment.exitcode 我也喜欢这样做，因为这样您就可以使用 FormatMessage() 或 C# var ex = new Win32Exception(code); Console.WriteLine(ex.Message); 检索有意义的字符串。请注意，ERROR_SUCCESS 定义为 0，因此此枚举与直接使用 AND/OR 逻辑测试退出代码的批次兼容。 stackoverflow.com/a/17085933/420400

【解决方案8】：

实现你将使用的东西。其他的都是多余的。

【讨论】：