-
Notifications
You must be signed in to change notification settings - Fork 292
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
Error plugin? #30
Comments
Yes, this was next on my list actually, and I have a few thoughts on it, but a count of errors would be a good start. An array of errors with their details might be better. The only issue with |
In practice, I find that the actual error details are often not helpful because minification has garbled the line numbers and identifiers. Would it be possible to support an option that lets callers who only want the error count to purge the details from their beacon requests? I have to confess, I've not looked thoroughly at the different types of error and how to catch them. I believe XHR errors are another that don't hit |
I took a stab at implementing error handler. It "replaces the original" XMLHttpRequest Constructor in it's window and adds EventListeneres for I'd love to see what you think of it: Even in the case where var req = new XMLHttpRequest();
req.open("GET", "/obvious404");
req.onerror = function() {
console.log("Error:", arguments);
};
req.onload = function() {
console.log("Load:", arguments);
};
req.send(); The result would be: (on the server)
Which as JSON would be: {
"status": 404,
"statusText": "File not found",
"responseURL": "http://localhost:8000/obvious404",
"timestamp": 1419229376346,
"loaded": 195,
"position": 195
} Thanks in advance! |
Hey Andreas, this looks good to me, but I spotted one small thing that might be wrong. Inside var ret = new impl.superObjects.XMLHttpRequest(arguments); I don't think you want to pass There are hacks for applying argument arrays to constructors invoked with the |
I just commited a fix for this: andreas-marschke@e7c2201 |
Hey andreas, I actually wrote a complete XHR wrapper. It's currently on bluesmoon/boomerang, can you have a look at that first? https://github.com/bluesmoon/boomerang What we still need is something to capture the global |
Hi all, Just trying to get the latest on this. I was looking for the error plugin. Is the one referenced by andreas the only error plugin that includes the window.onerror we can use currently with the latest version of Boomerang? I see on the SOASTA docs (http://docs.soasta.com/boomerang/#errors) a bit more info on the plugin but was wondering if this particular plugin was not open source. |
Hi @sridharangopal, SOASTA is currently testing a new Error plugin that will capture |
Great ... thanks for the update @nicjansma ... Any idea on the eta on this plugin to the open-source repo? |
Error plugin is available in #98 |
I guess this may be out of scope for boomerang; it's not performance-related although it is RUM.
But would there be any interest in a plugin that reports a simple count of the unhandled JavaScript errors caught by
window.onerror
?We measure this outside of boomerang at the moment, sending an aggregate count to our back-end on load and then sending any further increments as they occur. A graph of the mean count is a useful indicator because there are so many ways for a JS payload to break and affect the page, of which we'd otherwise be unaware.
Of course, it's no problem for us to continue doing this separately, but if you thought there might be a place for it here, I'm happy to put something together.
The text was updated successfully, but these errors were encountered: