(solved)Question about implicit wrapping during install()

1

Please forgive my ignorant question in advance. I’m just trying to learn Sentry a little, so we can leverage it most efficiently.

Just curious, what is the benefit in reporting the error here (https://github.com/getsentry/raven-js/blob/d20940823e380f1e0672433b197f9944d61afeb3/dist/raven.js#L366) and not just re-throwing it.

This way either traceKitWindowOnError() will report it if collectWindowErrors is set to ‘true’ or user defined onerror handler can deal with it.

We have a custom onerror handler that checks for common noisy errors from browser plugins/extensions and 3rd party vendors. We set collectWindowErrors to false and only send to sentry what is actionable. Unfortunately, everything that was wrapped via _instrumentTryCatch() via install() still gets sent to Sentry.

Maybe our setup is not optimal and we are trying to fit a square peg into a round hole, but still just curious. :slight_smile:

EDIT: Nevermind, I misunderstood this (https://blog.sentry.io/2016/01/04/client-javascript-reporting-window-onerror.html) article originally. For some reason, I thought that if you wrap in try/catch and rethrown, the 5th argument in onerror handler will magically appear (on older browsers like safari9).

2

In case future people don’t see your edit, we do this because:

  • It mitigates cross-origin CORS errors (“Script error.”)
  • It captures stack traces from “older” browsers with limited onerror support (this includes versions of Microsoft Edge, a “modern” browser)
  • We can generate “synthetic” traces when a non-error object is thrown (locate the source of the throw for debugging)

You can now disable this in 3.15.0 by setting the instrument config option to false, but I wouldn’t recommend it unless you have a good reason because you will lose some of the benefits above.

1 Like