Description
Based on #103
Users likely expect to be able to pass custom properties to errors when creating them via the shortcut methods such as createError.NotFound()
.
Proposed change would look something like:
const createError = require('http-errors')
createError.NotFound({message: "Aw shucks", data: { foo: "bar" } }) // does not work today
You need to use the createError({...})
form to pass custom properties to an error.
createError(404, {message: "Aw shucks", data: { foo: "bar" } })
There's a few caveats with the current implementation, namely you can't set status
via properties.
createError({ status: 404, message: "Aw shucks", data: { foo: "bar" } })
// status is ignored, will create a 500 server error with provided message and data fields
There is also a very high arity for createError
, which should be locked down into a stable interface.
(code)
for (var i = 0; i < arguments.length; i++) {
var arg = arguments[i]
var type = typeof arg
if (type === 'object' && arg instanceof Error) {
err = arg
status = err.status || err.statusCode || status
} else if (type === 'number' && i === 0) {
status = arg
} else if (type === 'string') {
msg = arg
} else if (type === 'object') {
props = arg
} else {
throw new TypeError('argument #' + (i + 1) + ' unsupported type ' + type)
}
}
Any of these changes would be semver major. There aren't plans for a major release of http-errors
yet, but these are things Im thinking about.
why did I put these both in one issue?
These are both topics related to the interfaces exposed by the library for accepting arguments, which can use some rethinking.