Sentry-javascript: Get rid of ignoreErrors

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 ​less 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 "" errors in Sentry. But my ignoreErrors is set to:
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!