-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
ignoreErrors list #291
Comments
@skovhus Yeah, that is true. Are you suggesting that it's problematic since I was going to change it to this, but I see your point. diff --git a/src/raven.js b/src/raven.js
index 6128169..d7bbbcb 100644
--- a/src/raven.js
+++ b/src/raven.js
@@ -76,12 +76,12 @@ var Raven = {
// "Script error." is hard coded into browsers for errors that it can't read.
// this is the result of a script being pulled in from an external domain and CORS.
- globalOptions.ignoreErrors.push('Script error.');
- globalOptions.ignoreErrors.push('Script error');
-
- // Other variants of external script errors:
- globalOptions.ignoreErrors.push('Javascript error: Script error on line 0');
- globalOptions.ignoreErrors.push('Javascript error: Script error. on line 0');
+ // Variants include:
+ // Script error.
+ // Script error
+ // Javascript error: Script error on line 0
+ // Javascript error: Script error. on line 0
+ globalOptions.ignoreErrors.push('script error');
// join regexp rules into one big rule
globalOptions.ignoreErrors = joinRegExp(globalOptions.ignoreErrors); |
Yes, it might hide too much. So either we are explicit and make the four rules regular expressions. In my eyes that is the correct thing to do... We will not be hiding anything else that the four cases. Else we could be less strict and just add |
A pull request for being more explicit #292 If you want to merge it, I will try it out on our site and check if we get some new external domain/CORS errors that the old less strict default |
Fixed with #292 |
👍 |
I made a comment back in #224 after it was merged. I guess you overlooked it, so I'll post it again:
I realize now that when adding a string to the whitelist filter, you don't start the regexp with a ^ or end it with $, e.g. the string can appear anywhere in the exception message. So these lines:
are actually covering
... Javascript error: Script error on line ...
error already. But alsoThis is a script error that should be handled...
... : /Is this deliberately? It is rather confusing. That also means that my last pull request #224 was covered by the old rules.
The text was updated successfully, but these errors were encountered: