Feature Request: Ability to attach custom properties to named errors

[jwater7]

Proposal

new createError.[code || name]([msg], [properties]))

Create a new error object with the given message msg.
The error object inherits from createError.HttpError.

var err1 = new createError.NotFound()
var err2 = new createError.NotImplemented('Route not implemented', { expose: true })

• code - the status code as a number
• name - the name of the error as a "bumpy case", i.e. NotFound or InternalServerError.
• msg - (optional) the message of the error
• properties - (optional) custom properties to attach to the object

[dougwilson]

Hi! This is implemented already though our factory function, which is our export and interface for creating errors. Here is an example:

var err2 = createError(501, 'Route not implemented', { expose: true })

I hope this helps!

[jwater7]

Hi @dougwilson ,

Thank you for the quick response. I am already aware of the normal createError() function as it is the only method to be able to assign custom properties like that and the one I am currently forced to use.

However, that is the exact reason for the feature request - it would be really nice to be able to also assign custom properties when creating "named" errors (without the need to know the error code number).

Please reopen the feature request unless you are saying that you do not think this is desirable - in which case I have supporting reasons that it is (ie interface consistency, error code abstraction, etc).

[dougwilson]

Hi, there has been multiple requests for the constructor and it is not desirable, no. You are always welcome to publish your own module to npm if that is a feature you want, even if it is just a wrapper to this module. The constructors were only exported for the use of instanceof checks and their signature marches that of what they inherit from: Error. If the javascript Error constructor adds the ability to pass in arbitrary properties this module would update to match, of course, to keep it consistent.

This module provides the factory as the method to construct errors. I know not everyone agrees with the interface, but I'm not going to force you to use this library :) you're always welcome to use a library that offers the API you prefer. That is what npm so great

[dougwilson]

duplicate of #29

If you feel strongly about this, please continue the discussion in the issue this is a duplicate of so that the history of conversation is not disjointed between many different issues. I should have directed the other duplicates to do the same, but that is my mistake, so the history in the duplicate is now incomplete.