Triage: Exit

[shadowspawn]

Commander calls exit under various circumstances, such as after displaying an error or the help. This is pretty convenient for the caller of a one-shot parse in a CLI, but is a problem when Commander is being used as part of a long running program or if caller wants more control over the failure handling.

Issues:

• optional exit value for Help. (feature request) #188 optional exit value for Help. (feature request)
• process.exit(64) #435 process.exit(64)
• Explicitly return when an error occurs #443 Explicitly return when an error occurs
• Make calls to process.exit() overridable #575 Make calls to process.exit() overridable
• Parse multiple commands without exiting the process #934 Parse multiple commands without exiting the process

Pull Requests:

• Add support for exit codes.  #436 Add support for exit codes.
• Explicitly return from error methods #444 Explicitly return from error methods
• Make process.exit() injectable. #576 Make process.exit() injectable.

[ngocdaothanh]

Yes, please simply throw errors. The outer program can catch the errors and handle them properly.

[shadowspawn]

I think being able to opt-in to using a throw makes good sense. But I think it is a bit untidy for default handling of expected errors with the source line number and code? Compared with just a message intended for humans.

[ngocdaothanh]

a bit untidy for default handling

To be backward compatible, we can add an option to:
Command.prototype.parse = function(argv)

like this:
Command.prototype.parse = function(argv, exitOnError = true)

[shadowspawn]

I am experimenting with a routine to optionally replace calls to process.exit. Since the most likely implementation is to throw, it is passed an Error ready to throw. e.g.

program.exitOverride((err) => { throw err; });

The custom error has properties for exitCode, code, and message. For example, the --version handling creates an error like this:

CommanderError(0, 'commander.version', this._version)

I'm currently just replacing the call to process.exit and not changing where or how the preceding messages are displayed. One thing at a time.

[shadowspawn]

There are improvements on the develop branch for the next release (#1040).

[shadowspawn]

v4.0.0-0 prerelease published: #1067

[shadowspawn]

v4.0.0 has been released. It does not cover all the exit related issues found in triage, but addresses the most common issue of the unconditional call to exit.

Feel free to open a new issue if still issues, with new information and renewed interest.