Skip to content
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

Get rid of ignoreErrors #73

Closed
mattrobenolt opened this issue Feb 12, 2013 · 18 comments
Closed

Get rid of ignoreErrors #73

mattrobenolt opened this issue Feb 12, 2013 · 18 comments

Comments

@mattrobenolt
Copy link
Contributor

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.

mattrobenolt added a commit that referenced this issue Feb 15, 2013
@mattrobenolt
Copy link
Contributor Author

I'll yank with 1.1

mattrobenolt added a commit that referenced this issue Feb 24, 2013
@jeremyhaile
Copy link

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.

@mattrobenolt
Copy link
Contributor Author

@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. :)

@jeremyhaile
Copy link

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?

@mattrobenolt
Copy link
Contributor Author

ignoreUrls takes an array of regex patterns. So you can do whatever you want. :)

@mattrobenolt
Copy link
Contributor Author

@jeremyhaile
Copy link

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.

@jeremyhaile
Copy link

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

@mattrobenolt
Copy link
Contributor Author

@jeremyhaile Fair enough. I'll keep it around. Thanks for letting me know!

@jeremyhaile
Copy link

No problem - appreciate the quick replies!

@jeremyhaile
Copy link

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.

@acdha
Copy link
Contributor

acdha commented Feb 26, 2013

+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.

@mattrobenolt
Copy link
Contributor Author

ISP-injected noise

That sounds good. 👍

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?

@acdha
Copy link
Contributor

acdha commented Feb 26, 2013

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.

@jeremyhaile
Copy link

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.

@jeremyhaile
Copy link

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)

@mattrobenolt
Copy link
Contributor Author

@jeremyhaile Can you open up a separate issue for that?

mattrobenolt added a commit that referenced this issue Mar 7, 2013
This reverts commit 34c3b3a.

Conflicts:
	src/raven.js
@mattrobenolt
Copy link
Contributor Author

I reverted this deprecation warning. It's just a bad idea. :)

Thanks for the input guys!

pieter added a commit to silkapp/raven-js that referenced this issue Mar 15, 2013
* reverse-stacktrace:
  Reverse stack traces
  Update for new Invoke
  includePaths, fixes getsentry#72
  Undeprecate ignoreErrors
  Actually handle global tags, fixes getsentry#82
  Update docs to reflect options and Pro Tips
  Revert "Removing ignoreErrors, explicitly only filter "Script error.""
  Revert "Deprecate ignoreErrors, see getsentry#73"
  Reference 1.0.7 in the docs
  Bump TraceKit
  Backfill 1.0.7

Conflicts:
	vendor/TraceKit
kamilogorek pushed a commit that referenced this issue Jun 12, 2018
expose more meta information on HTTP errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants