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
Comments
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 |
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? |
|
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 |
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? |
I think it having it be separate would be less confusing - otherwise it I do like the idea of either renaming it to make it clear that what you're |
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: On the server it says: 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? |
This reverts commit 34c3b3a. Conflicts: src/raven.js
I reverted this deprecation warning. It's just a bad idea. :) Thanks for the input guys! |
* 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
expose more meta information on HTTP errors
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.The text was updated successfully, but these errors were encountered: