-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide hook to add metadata #142
Comments
Well, you really shouldn't be using the fallback Raven explicitly monkey patches things so that it can be done with Today, if you use I can add a callback for |
Thank you for the quick response! You're right -- we shouldn't really be using window.onerror -- but there seem to be some exceptions that are otherwise very tricky to catch because of their async nature (although am working at "hooking" into these areas). A |
Yes, you would have to prepare the data beforehand. What is your usecase where you'd want to prepare on the fly? Just curious so I can construct a callback that makes sense. |
I should have mentioned that before, sorry. I want to send, along with the exception, details of the DOM events leading up to the exception. I have a function which intercepts dispatched jQuery events, logs them (throwing them away after 5000ms). If an exception occurs within 5000ms of the DOM event I will send info about that dom event within the This reminds me of another issue (#58). If my payload, including the dom-event stuff, is too big will it just error out? |
Why was this closed? To address your question, yeah, there is a limit to how much data you can send along with an error. But that limit has to do with your Sentry server (or getsentry.com). Very specific to configuring nginx or whatever you're using. Older browsers also have limits for the length of a url. And yeah, it'll silently fail if it's too long, unfortunately. If you configure your nginx to accept a really long uri and the target is modern browsers, you can make it work though. getsentry.com has a pretty large limit. |
Sorry for closing -- was about to add an explanation -- realised that the dom-event thing is moot (or should be) if we use source maps. |
Thank you for the info regarding the payload length. |
Ah yes, source maps are basically essential IMO. Let me know if you have any issues with that too. :) |
- fix(rrweb): Use unpatched requestAnimationFrame when possible [#150](getsentry/rrweb#150) - ref: Avoid async in canvas (#143) - feat: Bundle canvas worker manually (#144) - build: Build for ES2020 (#142)
- fix(rrweb): Use unpatched requestAnimationFrame when possible [#150](getsentry/rrweb#150) - ref: Avoid async in canvas (#143) - feat: Bundle canvas worker manually (#144) - build: Build for ES2020 (#142)
This bump contains the following changes: - fix(rrweb): Use unpatched requestAnimationFrame when possible [#150](getsentry/rrweb#150) - ref: Avoid async in canvas [#143](getsentry/rrweb#143) - feat: Bundle canvas worker manually [#144](getsentry/rrweb#144) - build: Build for ES2020 [#142](getsentry/rrweb#142) Extracted out from #9826 Closes #6946
It would be really nice if raven-js provided a mechanism for devs to add their own metadata (i.e. via the
extra
option). Right now, in order to do this, I have to take charge of catching my app's errors myself and then manually callingcaptureException
:I would prefer a way where I can still take advantage of Raven's default
window.onerror
handling. Maybe there is one that I'm not aware of?So I guess the question becomes: Is there a way to add
extra
data to every sent exception without having to catch the exceptions myself?The text was updated successfully, but these errors were encountered: