You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide a new hook for harvesting "extra" data from an Error object #483
+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.
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).
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.
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 :)
Activity
pkaminski commentedon Feb 3, 2016
+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.
benvinegar commentedon Nov 23, 2016
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
dataCallbackto 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 adataCallbacksignature that looks likefunction (data, originalCallback, originalError).Sigh.
joshma commentedon Nov 23, 2016
It wouldn't match the node library, which may be enough reason to rule it out, but IMO just reading the
error.extrafield could be a 4th option. It's easy to use and avoids accidentally collecting too much data.robertsami commentedon Nov 23, 2016
Agreed with 4th option, but also putting in a vote for the second option listed by @mattrobenolt "Provide a new hook to preprocess the
Errorwhere these can be extracted". Avoids memory issues, preserves flexibility, and does not lead to adataCallbacksignature you're not fond of :)Add an errorCallback for adding data details from the raw error object
Add an errorCallback for adding data details from the raw error object
blittle commentedon Dec 15, 2016
I just added a PR for the second option. Would love feedback!