This is a remnant of pre 1.0 days with the "Script error."
issue, but this has since been hardcoded into raven. It doesn't really help with anythign else.
I'll yank with 1.1
I've got tons of errors I ignore. Why is this being removed? For example - I was continually getting an error that I finally traced back to be some random Firefox plugin that generated a spurious error. There was nothing I could do about it - so I added it to ignoreErrors.
@jeremyhaile Would you be able to get around it with ignoreUrls
instead? If not, I'll keep it around. I was under the impression that nobody used this and it was just adding bloat. :)
Hmm - good question. If I add a URL like "http://static.ak.facebook.com/" to ignoreUrls, does it ignore all errors that come from any directory/file that starts with that URL?
ignoreUrls
takes an array of regex patterns. So you can do whatever you want. :)
@jeremyhaile Specifically: https://github.com/getsentry/raven-js/blob/master/src/raven.js#L374
OK - I'm going to try deleting ignoreErrors from our configuration and see what errors I start receiving and if ignoreUrls allows me to ignore them or not. I'll let you know what I find.
Yeah - I'm already running into errors that I can't (or don't care about) fixing and that can't be excluded using ignoreUrls. Here is one such IE error I'm already receiving. The recommended fix according to Microsoft is "upgrade to IE8" And the URL is showing up as my page URL, which I obviously don't want to exclude. http://support.microsoft.com/kb/927917?wa=wsignin1.0
@jeremyhaile Fair enough. I'll keep it around. Thanks for letting me know!
No problem - appreciate the quick replies!
It would be nice if ignoreErrors used regexes like ignoreUrls does instead of exact match strings. In some cases, I'm running into errors that have a strange error code attached that is not always the same number. Or errors that contain the same string but have different prefixes in different browsers.
+1 to @jeremyhaile's suggestion - either making it use regexps or perhaps refactoring it into something like ignoreErrorPatterns
would help denoise a few bits of extension / ISP-injected noise which I see on our public site.
ISP-injected noise
That sounds good. :+1:
I'm all for regexes. Do you think it makes sense to essentially merge these two options into one that just works for either urls or message names?
Or should they still be separate?
I think it having it be separate would be 鈥媗ess confusing - otherwise it
seems almost certain that someone will open an issue because their regexp
matched more than they expected.
I do like the idea of either renaming it to make it clear that what you're
providing is a regular expression or explicitly checking for string vs.
regexp to decide whether to test using ==
or .test()
to avoid surprises.
I agree keeping it separate - I can't think of cases where I wouldn't explicitly be writing a regex for the URL vs the message. Also - if I'm writing URL regex, it's inefficient to compare it to every message.
I also like your idea of checking if it's a string or regex before doing the comparison.
I'm having an issue with ignoreErrors (perhaps fixed with regex?) where I'm receiving hundreds of "
ignoreErrors: ['
On the server it says:
9 minutes ago javascript
Any idea why this wouldn't be filtered? Let me know if I should open a separate issue for this. (and perhaps the regex issue as well)
@jeremyhaile Can you open up a separate issue for that?
I reverted this deprecation warning. It's just a bad idea. :)
Thanks for the input guys!
Most helpful comment
I reverted this deprecation warning. It's just a bad idea. :)
Thanks for the input guys!