相关(但不同):How do I look up the proper Windows System Error Code to use in my application?
我的C#控制台应用程序正在进行一种文件类型和第二种文件类型之间的转换(为方便起见,我们称之为*.x
和*.y
;用户必须将两个文件的完整路径指定为命令行参数。
通常情况下,我有相当多的逻辑来验证命令行参数。每当出现验证错误时(显然,在向用户打印出相应的消息后),我在应用程序中使用Environment.Exit。
Microsoft有大量list错误代码。与我最直接相关的是0
(流程成功运行)和1
(找不到文件)。
我的命令行参数的错误情况/验证规则如下:
*.x
或*.y
以外的其他内容。)*.x
文件和*.y
文件。Environment.Exit(1);
(因为这是Microsoft的文档所说的正确的错误代码是针对未找到的文件)。我的问题是:鉴于我已经告诉用户确切的错误是什么,如果违反了其中一个验证规则(例如,如果找不到该文件),我实际上是从{{1}获得了什么} (例如)?我从文档中确实知道它会将我指定的错误代码返回给操作系统,但这实际上对我有什么帮助(特别是从编写“纯”.NET应用程序而没有“低级”操作的角度来看)?那时操作系统实际上做了哪些不同的事情,它如何使用户(或我自己的调试)受益?
我是否必须在我的应用程序中执行任何“特殊”操作才能从中获得最大收益?
答案 0 :(得分: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脚本中运行并且作者希望根据执行结果执行某些操作时也是如此。
简而言之 - 您的错误消息供人类使用,退出代码适用于机器。因此,在成功或其他任何事情(通常为1)出错时返回0。如果您的程序设计用于与其他工具(如许多unix工具)一起使用的大量命令行消耗 - 您可能希望对不同的条件使用多个退出代码并记录它们 - 但这不是这里的情况。而且您不需要使用Environment.Exit
- 只需更改Main
的签名即可返回int:
static int Main(string[] args) {...}