Why and how to use Windows System Error Codes with Environment.Exit

Related (but different): How do I look up the proper Windows System Error Code to use in my application?

My C# console application is doing conversion between one file type and a second file type (let's call them *.x and *.y for convenience); the user must specify the full paths of both files as command line parameters.

As is typically the case, I have a decent amount of logic to validate the command line arguments. I'm using Environment.Exit in the application whenever there was a validation error (obviously, after printing out the appropriate message to the user).

Microsoft has a very extensive list of error codes. The most immediately relevant ones for me are 0 (process ran successfully) and 1 (file not found).

The error cases/validation rules for my command line parameters are as follows:

My question is: given that I already tell the user exactly what the error was if one of the validation rules is violated (e.g. if the file couldn't be found), am I actually gaining anything from doing Environment.Exit(1); (for example)? I do realize from the documentation that it'll return the error code I specify to the operating system, but how does that actually help me (especially from the perspective of writing a "pure" .NET application with no "low-level" operations)? What does the operating system actually do differently at that point, and how does it benefit the user (or my own debugging)?

Do I have to do anything "special" in my application to get the maximum benefit from this?

Upvotes: 2

Views: 712

Answers (1)

Evk
Evk

Reputation: 101463

That exit code can be used by any other process which spawned process with your application. For example, sometimes you want to call external tool (such as ffmpeg) from your C# application. You are doing something like :

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

After doing that you want to know if all went fine or not. It's hard for a program to analyze error output or something like that - so you just check:

bool allFine = ffmpeg.ExitCode == 0;

Because general convention (in all operating systems I'm aware of) is to return 0 for success). Granted, it does not always work, but that is because not all tools follow this useful convention to return 0 for success and 1 for error, so you should be on a good side and follow that.

Same is true when your application is run in the middle of long .bat script and author wants to perform certain actions depending on result of execution.

In short - your error messages are for human consumption while exit codes are for machines. So return 0 on success or anything else (usually 1) on error. If your program is designed for extensive command line consumption in combination with other tools (like many unix tools) - you might want to use several exit codes for different conditions and document them - but it's not the case here. And you don't need to use Environment.Exit - just change signature of Main to return int:

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

Upvotes: 1

Related Questions