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

Error plugin? #30

Closed
philbooth opened this issue Jun 5, 2014 · 10 comments
Closed

Error plugin? #30

philbooth opened this issue Jun 5, 2014 · 10 comments

Comments

@philbooth
Copy link

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.

@bluesmoon
Copy link
Member

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 window.onerror is that it doesn't capture errors that happen in event handlers. We could look for standard libraries that capture those errors and log them as well, but that might add bloat. What do you think?

@philbooth
Copy link
Author

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 window.onerror too? If the burden of trying to trap all of the different types is too great, perhaps we could expose something that lets the caller take care of the actual trapping part?

@andreas-marschke
Copy link

I took a stab at implementing error handler. It "replaces the original" XMLHttpRequest Constructor in it's window and adds EventListeneres for abort and error.

I'd love to see what you think of it:
https://github.com/andreas-marschke/boomerang/blob/onerror/plugins/error.js

Even in the case where onerror gets overwritten by another script in the page errors should still be reported. So even this would get reported:

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)

status=404&statusText=File%20not%20found&responseURL=http://localhost:8000/obvious404&timestamp=1419229251359&loaded=195&position=195&

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!

@philbooth
Copy link
Author

Hey Andreas, this looks good to me, but I spotted one small thing that might be wrong.

Inside replaceObjects, you construct the XHR instance like this:

var ret = new impl.superObjects.XMLHttpRequest(arguments);

I don't think you want to pass arguments without either unpacking it first or applying the function rather than calling it.

There are hacks for applying argument arrays to constructors invoked with the new operator but, in this case, you may not need them. I believe it is only the Mozilla implementation that accepts an argument to that constructor, so just passing arguments[0] instead should work cross browser.

@andreas-marschke
Copy link

I just commited a fix for this: andreas-marschke@e7c2201

@bluesmoon
Copy link
Member

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 window.onerror.

@sridharangopal
Copy link

sridharangopal commented Apr 15, 2016

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.

@nicjansma
Copy link

Hi @sridharangopal, SOASTA is currently testing a new Error plugin that will capture window.onerror and more. It should be included in the next round of things we backport to the open-source repo.

@sridharangopal
Copy link

Great ... thanks for the update @nicjansma ... Any idea on the eta on this plugin to the open-source repo?

@nicjansma
Copy link

Error plugin is available in #98

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants