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
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 calling captureException:
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 Raven.onException would be incredibly useful I think -- it'd enable people to add metadata at the time of exception too, which I don't think is possible with context/wrap (with them, you have to prepare the metadata beforehand).
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 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 extra data. Stack traces on minified sources don't give enough info to determine where the problem is (e.g. error @ line 1, which contains 10000 characters) -- so I was thinking of sending some additional info along, and "dom events leading to an error" seemed like the wisest choice at the time. (interested if you have any thoughts about this)
This reminds me of another issue (#58). If my payload, including the dom-event stuff, is too big will it just error out?
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.
Activity
mattrobenolt commentedon Oct 16, 2013
Well, you really shouldn't be using the fallback
window.onerroranyways. That's a last ditch effort.Raven explicitly monkey patches things so that it can be done with
Raven.captureError.Today, if you use
Raven.contextorRaven.wrap, you're able to pass along your own extras. See: http://raven-js.readthedocs.org/en/latest/usage/index.html#passing-additional-dataI can add a callback for
Raven.onExceptionor something that you can register to patch on more stuff at a global context though.padolsey commentedon Oct 16, 2013
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
Raven.onExceptionwould be incredibly useful I think -- it'd enable people to add metadata at the time of exception too, which I don't think is possible with context/wrap (with them, you have to prepare the metadata beforehand).mattrobenolt commentedon Oct 16, 2013
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.
padolsey commentedon Oct 16, 2013
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
extradata. Stack traces on minified sources don't give enough info to determine where the problem is (e.g. error @ line 1, which contains 10000 characters) -- so I was thinking of sending some additional info along, and "dom events leading to an error" seemed like the wisest choice at the time. (interested if you have any thoughts about this)This reminds me of another issue (#58). If my payload, including the dom-event stuff, is too big will it just error out?
mattrobenolt commentedon Oct 17, 2013
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.
padolsey commentedon Oct 17, 2013
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.
padolsey commentedon Oct 17, 2013
Thank you for the info regarding the payload length.
mattrobenolt commentedon Oct 17, 2013
Ah yes, source maps are basically essential IMO. Let me know if you have any issues with that too. :)
Merge pull request #142 from getsentry/better-node-docs
feat(replay): Update rrweb to 2.7.3
feat(replay): Update rrweb to 2.7.3
feat(replay): Update rrweb to 2.7.3 (#10072)