Node: Error convenience subclasses

[benjamingr]

The string new errors.TypeError('ERR_INVALID_OPT_VALUE', repeats almost 30 times in our code base.

I think it would be nice if we had an InvalidOptionValue subclass to deal with these specifically.

I'm afraid it might have impact on users explicitly checking the name string of errors - but that seems a lot less common than a instanceof TypeError that would still pass and we can override .name explicitly. We can also make it a factory and not a class so it doesn't affect it:

function InvalidOptionValue(name, value) {
  return new errors.TypeError('ERR_INVALID_OPT_VALUE', name, value); 
}

What do you think?

[BridgeAR]

I personally do not see much benefit by introducing another abstraction.

[mscdex]

I agree with @BridgeAR

[jasnell]

As much as I dislike duplicated code, I'd have to agree with @BridgeAR and @mscdex. The added layer of abstraction just ends up hiding the details. (It also ends up adding an unnecessary frame to the stack trace, fwiw).