Skip to content

Interface changes #104

Open
Open
@jonchurch

Description

@jonchurch

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions