Ability to supply an array of valid/accepted exitcodes.

[nixtar]

Use case(s)

Some processes use non zero exitcodes when running successfully.
For EG robocopy: https://ss64.com/nt/robocopy-exit.html and msiexec

Description

Add a int array parameter to Run, RunAsync, Read and ReadAsync that defaults to new int[] { 0 }.
Then change the current logic that checks if the exit code is not 0 to check that its not in the array.
To prevent breaking changes add new ExitCodeException and continue to throw NonZeroExitCodeException if the expected exit code only contains 0?
Or make parameter null by default and do a null check and throw NonZeroExitCodeException if null and exit code is non zero.

Alternatives

Consumer of this library catches NonZeroExitCodeException and implements their own exit code checks.

[adamralph]

hi @nixtar, thanks for raising this. It's a shame that there are widely used programs which do not conform to the non-zero-for-failure convention, but given that is the case, this feature request seems reasonable.

Just to explore alternatives, what about an optional delegate that allowed you to take control of the handling of exit codes?

Off the top of my head, something like:

Run("foo.exe", handleExitCode: exitCode => { ... });

If the delegate is present, then SimpleExec would bypass it's normal handling and call the delegate instead.

[adamralph]

Or perhaps the delegate could return a Boolean to indicate that it has handled the exit code, where true means handled and false means unhandled. So, given that robocopy exit codes 0-7 indicate success, your code would look something like:

Run("robocopy", handleExitCode: exitCode => exitCode < 8);

[adamralph]

Actually the Boolean proposal, like your original proposal, wouldn't make sense as long the exception is named NonZeroExitCodeException. If we pursue either of those proposals, I wouldn't mind obsoleting NonZeroExitCodeException in favour of a new ErrorExitCodeException. The new exception would inherit from the old exception until the next major version bump.

[adamralph]

Thanks again for raising this @nixtar. I'm replacing it with the more general solution described in #313.