Make errors programmatically processable

[ericelliott]

Make errors programmatically processable

[tjconcept]

Intuitively, I would categorise both of those errors as "implementation errors" or "programmer errors" that should not be caught but blow up the stack and exit the process. The reason I believe so is that they are checking that your input is not violating the interface/specification rather than being operational errors. They are simply sort of a helping hand during implementation and for debugging, and even removing those checks would be, in my opinion, entirely legit.

[medikoo]

Intuitively, I would categorise both of those errors as "implementation errors" or "programmer errors"

@tjconcept definitely and linked errors are implementation (controlled) errors, it would be good to give them some recognition.

On my side when there's malformed hash stored in database I want to (in controlled way): reject login attempt and log event, but not crash the process. While current options that I have are:

a) Crash (overreaction, as I can handle some recognizable errors gently and allow process going)
b) Introduce some hard to maintain not future proof error detection
c) Catch all errors, this is bad as it will also catch programmatical errors (e.g. eventual bugs in credential) that doesn't seem solid.

[medikoo]

btw. Node.js migrated all errors recently to be equipped with such codes (for this very reason of programmatical recognition) -> https://github.com/nodejs/node/blob/master/doc/guides/using-internal-errors.md#adding-new-errors

[tjconcept]

Catch all errors, this is bad as it will also catch programmatical errors

This is exactly my argument. These are such errors you do not want to catch.

Anyways, I think the idea of having a code is fine, and aligning with Node.js as well makes sense.
Whether to catch such error is another matter, in which it seems we don't agree entirely.

[medikoo]

Whether to catch such error is another matter, in which it seems we don't agree entirely.

Exactly, and this decision should not be made (or forced) by credential. It's library dependent that should be in power to decide :)

[tjconcept]

Well, we don't agree on that either xD It's linked to my former argument that removing these throw would be a completely sane move as well. They are only there to help you during integration. You could add 100 of these input checks if you wanted.
For the same reason the dependent libraries should not catch these: it would be completely arbitrary which programming errors would be caught or not.

[ericelliott]

Closing all stale issues and PRs. Please update, ensure all tests pass, and reopen if you really want this in.