Establish error message approach

[joesepi]

See: #1 (comment)

Whoops!

[joesepi]

Let's try to mirror what Node does in a minimal fashion but could be easily ported over when/if the time comes.

[joesepi]

Another question in today's meeting: Should we ever Throw an error? Or should we always return and on error, return an error object?

The consensus is we should avoid throwing an error and prefer to return an error object and allow the consumer of parseargs to manage error handling.

[ljharb]

Typically I throw a string from argument validation, because throwing an error causes node to print stack trace info that's undesirable.

It would also be fine to let the consumer handle it, but since there's no robust way of identifying error objects, i'd prefer a two-channel mechanism like Promise.

[joesepi]

For reference: https://github.com/nodejs/node/blob/master/lib/internal/errors.js

[shadowspawn]

For my command-line work, I make a distinction between errors which are due to programmer error and errors which are encountered at runtime due to usage errors on the command line. For the programmer errors I throw Error, very noisy but the stack is at least potentially helpful for the programmer to find and fix the coding error.

[ljharb]

In my yargs packages i throw strings instead of errors for arg validation, for that reason.

[bcoe]

I think it's less important that we figure out the wording of errors, when we merge into the Node.js codebase we will model after other errors...

More importantly, I like @shadowspawn's suggestion that we go through the codebase and determine which errors could be categorized as input errors, vs., programming errors, and decide how we handle each:

• do we throw on input errors, or perhaps populate an error string instead?

[shadowspawn]

do we throw on input errors, or perhaps populate an error string instead?

There have been a few people suggesting that parse never "fails" on user input, and perhaps error information could be a property in the results. I see the attraction and interested in trying that approach. [Edit: I am no longer interested in quietly returning errors, doubtful it will be useful enough.]

In line with the description and intent of strict, the implementation could be parseArgs throws the input-error string if strict, and quietly returns the input-error string if !strict.

(I am personally of the view that if the input does not match the programmers intentions then the outcome is in doubt. But a key part of the proposal is zero-setup parsing, and I can turn on strict to get more certainty.)