Skip to content

Provide a new hook for harvesting "extra" data from an Error object #483

Closed

Description

@mattrobenolt

It's semi-common practice to tack on additional properties onto an Error object.

Something like:

var err = new Error('lol');
err.thing = 'something awesome happened';
throw err;

And these additional properties are useful in lots of cases.

We need a hook to provide a way to collect this information and transform it into extra data that gets passed along.

We have 3 options here:

  • Collect all properties automatically and hope we don't blow up our data limits.
  • Provide a new hook to preprocess the Error where these can be extracted
  • Augment dataCallback to provide the Error so they can inspect and modify the data packet themselves.

Activity

  1. pkaminski commented on Feb 3, 2016

    @pkaminski
    Contributor

    +1 on any/all of these options. Option 1 would match the Node library's behavior (I believe), but having a hook that gets access to the original error would also be useful in other cases.

  2. benvinegar commented on Nov 23, 2016

    @benvinegar
    Contributor

    My only concern here is that we blow up memory usage by automatically collecting extra attributes, since raven-js can't gzip like raven-node does.

    The callback approach seems easiest, but we'd need dataCallback to accept a 2nd argument (the original error), but we've already started using that argument to pass an "original" callback if one existed previously. I'm not fond of a dataCallback signature that looks like function (data, originalCallback, originalError).

    Sigh.

  3. joshma commented on Nov 23, 2016

    @joshma

    It wouldn't match the node library, which may be enough reason to rule it out, but IMO just reading the error.extra field could be a 4th option. It's easy to use and avoids accidentally collecting too much data.

  4. robertsami commented on Nov 23, 2016

    @robertsami

    Agreed with 4th option, but also putting in a vote for the second option listed by @mattrobenolt "Provide a new hook to preprocess the Error where these can be extracted". Avoids memory issues, preserves flexibility, and does not lead to a dataCallback signature you're not fond of :)

  5. blittle commented on Dec 15, 2016

    @blittle

    I just added a PR for the second option. Would love feedback!

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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions