为什么以及如何在 Environment.Exit 中使用 Windows 系统错误代码答案

【问题标题】：Why and how to use Windows System Error Codes with Environment.Exit为什么以及如何在 Environment.Exit 中使用 Windows 系统错误代码
【发布时间】：2017-12-03 10:39:51
【问题描述】：

我的 C# 控制台应用程序正在一种文件类型和第二种文件类型之间进行转换（为方便起见，我们称它们为 *.x 和 *.y）；用户必须指定两个文件的完整路径作为命令行参数。

通常情况下，我有大量的逻辑来验证命令行参数。每当出现验证错误时，我都会在应用程序中使用Environment.Exit（显然，在向用户打印出适当的消息之后）。

Microsoft 有一个非常广泛的错误代码list。对我来说最直接相关的是0（进程运行成功）和1（找不到文件）。

我的命令行参数的错误案例/验证规则如下：

用户提供的命令行参数过多（超过 2 个）。这意味着用户必须包含不相关的参数。
用户提供的命令行参数太少（少于两个）。这意味着用户没有提供这两个文件的路径。
一个或多个参数的文件类型无法识别（即不是*.x 或*.y）。
用户没有同时提供*.x 文件和*.y 文件。
用户提供的路径中不存在一个或两个文件。在这种情况下，我假设正确的调用是 Environment.Exit(1);（因为 Microsoft 的文档中说正确的错误代码是针对未找到的文件）。

我的问题是：鉴于我已经告诉用户如果违反了验证规则之一（例如，如果找不到文件）会出现什么错误，那么我真的从Environment.Exit(1);（例如）？我确实从文档中意识到它会将我指定的错误代码返回给操作系统，但这实际上对我有什么帮助（特别是从编写没有“低级”操作的“纯”.NET 应用程序的角度来看)?操作系统在这一点上实际上做了什么不同，它对用户（或我自己的调试）有什么好处？

我是否必须在我的应用程序中做一些“特别”的事情才能从中获得最大的好处？

【问题讨论】：

另外，你不能只从 main 方法返回一个 int 吗？不知道您是否需要/应该使用 Environment.Exit - 我认为这更像是一个“杀死进程并返回一个数字”
@Derek 是的，我想我也可以这样做。
只使用 0 表示成功，使用其他任何值表示错误。当一个进程产生另一个进程并想要检查一切是否正常时，这一点很重要。例如，如果您在 C# 中生成进程并调用 WaitForExit - 您想知道一切是否正常。当您在某个脚本（例如 .bat 文件）中调用该程序并且如果某个步骤（调用您的应用程序）失败时不想继续执行您的脚本时，同样适用。
@Evk 好点，我可以看到这在这些情况下会有什么用处。您的评论实际上可能就是答案。

标签： c# .net windows error-handling

【解决方案1】：

该退出代码可以由任何其他与您的应用程序产生进程的进程使用。例如，有时您想从 C# 应用程序调用外部工具（例如 ffmpeg）。你正在做类似的事情：

var ffmpeg = new Process();
ffmpeg.StartInfo = new ProcessStartInfo("ffmpeg.exe", "args");
ffmpeg.Start();
ffmpeg.WaitForExit();

这样做之后，您想知道一切是否正常。程序很难分析错误输出或类似的东西 - 所以你只需检查：

bool allFine = ffmpeg.ExitCode == 0;

因为一般惯例（在我知道的所有操作系统中）是返回 0 表示成功）。当然，它并不总是有效，但这是因为并非所有工具都遵循这个有用的约定，成功返回 0，错误返回 1，所以你应该站在好的一边并遵循这一点。

当您的应用程序在较长的 .bat 脚本中运行并且作者希望根据执行结果执行某些操作时也是如此。

简而言之 - 您的错误消息是供人使用的，而退出代码是供机器使用的。因此，成功时返回 0，错误时返回任何其他值（通常为 1）。如果您的程序设计用于与其他工具（如许多 unix 工具）结合使用广泛的命令行消耗 - 您可能希望针对不同的条件使用多个退出代码并记录它们 - 但这里不是这种情况。而且您不需要使用Environment.Exit - 只需更改Main 的签名即可返回int：

static int Main(string[] args) {...}

【讨论】：

谢谢，这很有意义。