Skip to content

5.x planning #55

Closed
Closed

Description

@DonutEspresso

(not to be confused with restify's 5.x)

Remove a lot of the logic around the context property and simply use VError's info property. This will necessitate a reworking of the variadic args parsing, since an options object as a first parameter is what we used to differentiate custom restify-errors logic vs straight pass through to VError. This will be a breaking change to the API. It might be worth re-evaluating what this module brings to the table on top of VError now that VError is able to do most of what this module does. In my mind, those things are:

  • Pre-defined constructors for all http 4xx/5xx errors
  • Ability to create pre-defined constructors. VError allows you to create typed errors in-situ, but does not expose sugar APIs for creating a constructor itself, which can be a lot of boilerplate if you have many custom constructors.
  • Bunyan serializers for err.context and err.info. This, arguably, should be an independent module.

Would appreciate any feedback from folks who are using this module.

Activity

  1. changed the title [-]5.x release[/-] [+]5.x planning[/+] on Sep 1, 2016
  2. noderat commented on Jan 23, 2017

    @noderat

    I'm just now starting to use this package, however all of your suggested points sound fantastic! I'm especially interested in sticking with VError since everything I do lately seems to result in an array of promises, and VError can be converted to WError for production. Additionally the serializers sounds fantastic since I'm using restify-errors with express-pino-logger and the bunyan serializer already helpful. It would also be useful if this could expose VError and WError directly (limits potential version incompatibility issues)

  3. retrohacker commented on Aug 11, 2017

    @retrohacker

    @DonutEspresso mind breaking this out into feature requests? No rush, this module is stable as is, but we have had problems with staging a lot of changes for releases in the past 😄

    We can just leverage conventional changelog to cut major releases as bits of this land.

  4. DonutEspresso commented on Aug 16, 2017

    @DonutEspresso
    MemberAuthor

    This really only boils down to a single feature - opened a new ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions