promisify-child-process
promisify-child-process copied to clipboard
jcoreio
Option to not throw on non-zero exit code
It seems to throw on non-zero exit code. I would like to avoid wrapping in try/catch, and read the code.
The documentation has an example showing usage of the {code} in the result. This is confusing because you cannot read the code it if throws.
The default behavior is fine as it matches Node's promisify behaviour: https://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback
If this method is invoked as its util.promisify()ed version, it returns a Promise for an Object with stdout and stderr properties. In case of an error (including any error resulting in an exit code other than 0), a rejected promise is returned, with the same error object given in the callback, but with an additional two properties stdout and stderr.
Accessing the code from the result should be removed from the docs, or an example should be added showing the need to try/catch on failure.
@vjpr Yeah I need to improve the docs, thanks for pointing this out. If it throws, you can read error.code, error.signal, just like child_process.exec. This lib also attaches stdout and stderr to the error it throws. Instead of wrapping in try/catch, you can add .catch(e => e) (even within an async function) and then read code, signal, stdout, and stderr on the result regardless of whether it threw or not.
However, I should also attach these properties in the case the ChildProcess emitted an error...
And I should add code/signal to the result if it succeeded as well.
.catch(e => e) was what I was needing. Thanks!
However, I should also attach these properties
Would be good.
would the following code work to capture exit code in all success and failure cases?
child.on('exit', (code) => {
doWhateverWithCode(code);
});
@ranasaria Well if the process exits because of a signal, code will be undefined, instead the signal argument will be defined. Otherwise that should work.
@vjpr Yeah I need to improve the docs, thanks for pointing this out.
I read your docs, noticed that you were returning the exit code, and assumed that I would not need to catch an exception if the child process exited non-zero. I would recommend changing either the behavior or the docs.
Thanks for the lib :+1:
