Sentry-javascript: Get original exception object in `shouldSendCallback`

[OliverJAsh]

I want to access the original exception object in shouldSendCallback, so I can choose how to log it.

Could we add this?

[dcramer]

@OliverJAsh iirc things should actually re-throw by default. How do you have things integrated? i.e. if you're using try/catch you'd effectively want to throw afterwards.

[mattrobenolt]

Yeah, rethrowing happens by default from captureException, and it'd be awkward to rethrow inside shouldSendCallback.

[mattrobenolt]

For context: https://github.com/getsentry/raven-js/blob/master/src/raven.js#L249

[OliverJAsh]

My mistake!

[OliverJAsh]

Actually we don't rethrow the error for captureException: https://github.com/getsentry/raven-js/blob/master/src/raven.js#L240-251

(We only throw if the exception is different from the original, i.e. one produced by the internals of TraceKit.report.)

We do, however, re-throw the error for wrap: https://github.com/getsentry/raven-js/blob/d3e70256b6d1dfcfd20ddae89d0d7acd3403b579/dist/raven.js#L1254. In these cases, I am catching the rethrown error myself.

So my original request remains: I would like access to the original error object from inside of shouldSendCallback, so I can _choose how to log it for both raven.wrap and raven.captureException_.

[OliverJAsh]

It would also be nice to know if the error was caught or uncaught, i.e., if it came from window.onerror then it is uncaught, otherwise it is caught. This would allow me to add logging for caught exceptions, i.e. by raven.context/wrap:

shouldSendCallback: function (data) {
    if (data.isCaught) {
        console.log('Caught error:', data.originalError.stack);
    }
}

Uncaught exceptions are already logged by the browser.

[dcramer]

I'm going to close this out as it's very unlikely we'd provide the error object at this point. The use-case is abusing a function which is only intended to say "should I send this upstream or not". More importantly, the error object should long be gone by the time this code path is hit, and if there needed to be something related to that it should happen much earlier in the process.

[OliverJAsh]

@dcramer How would you propose logging the errors captured by Raven (along with their stack traces)?

[dcramer]

@OliverJAsh we could add a hook for it, but being that generally we re-raise they should get logged by default in environments. Envs where upstream is catching them would be able to implement their own logging via an abstraction.

[OliverJAsh]

Another reason you might want access to the original exception in this callback is because the error might contain metadata which you need to use in your shouldSend logic.

We often catch errors to report them with extra metadata, but we then want to throw them again (to let the browser handle it as an uncaught exception) but prevent Raven from logging the error again when it reaches onerror.

Would you consider this a plausible use case @dcramer? Could we re-open?

[OliverJAsh]

For example:

                        raven.captureException(err, {
                            tags: {
                                feature: 'weather'
                            }
                        });
                        err.reported = true;
                        throw err;

[dwelle]

I second this.. our error objects contain metadata which are needed to determining whether to prevent the error from being sent to sentry.

[joachimroeleveld]

I also see the usecase for a filter function that can filter out errors based on more granular information via a callback.

[dcramer]

https://github.com/getsentry/raven-js/issues/980