Error Handling for Commands

[mark-studer]

What is the expectation around error handling for commands? I often wrap native command so I can get good error handling for automation situations. This generally means checking the $LASTEXITCODE to validate the command completed successfully. I did a test wrapping git and if the command fails you get no error. Looking at the generated command it has no error checking around the execution. Is there a way to enable that in the .json file or a plan for adding built-in or opt-in error handling?

[theJasonHelmick]

You raise an excellent point and we should consider error handling. I haven't added this to a milestone yet, but let's open the discussion here and get everyones feedback regarding concerns and implementation ideas.

[ethanbergstrom]

+1 on error handling. Chocolatey packages, for example, allow the package owner to specify a list of successful exit codes, and everything else gets treated as an error. Without a programmatic way to catch and handle error signals returned by the native command, we're left trying to guess how to parse the native command output for "uniquely error-like" text and throw an exception in the handler.

[kstrauss]

A few things that occur to me:

1. need to be able to specify a list of "good" return codes or a list of bad ones. Some applications have a return code say that means finished with warnings. Not sure how to represent other than perhaps a flag of TreatWarningsLikeErrors
2. Need to be able to ignore the return code and instead delegate to a function/script that deduces it from output (because the return code is always 0). Ideally, I would like a set of established ones (i.e. any output to stderr is an error, regex for pattern)
3. potentially add a list of handling strategies (throw exception, have a retry, retry with backoff, timeout, etc. like exists in Polly ) that should be added as parameters/switches on the generated wrapper. Should still support standard parameters like ErrorVariable