Error Handling for Commands #115
Replies: 4 comments 3 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
+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. |
Beta Was this translation helpful? Give feedback.
-
A few things that occur to me:
|
Beta Was this translation helpful? Give feedback.
-
there's not much here that's really actionable, so I've turned this into a discussion. The one approach I can see would be along the lines of the following:
The whole error delegate suggestion seems very fragile and over complicated, i'd love to know how this would work in practice. off the top of my head i see something like: "errorhandling": [
{
"lastExitCode": 3,
"handlerType": "inline",
"handler": "throw 'whoops - badness has ensued'"
},
] when the LASTEXITCODE matches, the error handler is called before calling the output handler. The error handler can receive the output of the faulting command so it can do whatever it wants. If the error handler throws or emits a terminating error, the output handler is not called, otherwise whatever output is handed to the outputHandler. It seems to me that retrying or whatever faulted situation becomes ridiculously complicated to do generically. |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions