You Really Should Log Client-Side Errors.
This isn’t something I’ve really thought much about implementing but makes a lot of sense. With so much being offloaded to the client side, there’s an increased potential for errors. We’ve got our test driven development and do what we can to write bug-free code, but as things continue to shift, that issue is going to only become more prominent.
By simply binding the window.onerror event, we can pass along any errors that pop up to the log on our server via AJAX. As per the article, we can hook into ajaxError as well, but there’s a small can of worms opened when doing that.
Aside from the neat walkthrough, this can really get you thinking about better handling client side errors you may be missing at this point. As per the comments, there are some additional issues to take into consideration like a malicious abuse of the system resulting in full hard drives on the server. Naturally appropriate precautions should be taken to avoid such issues, but we’re already potentially exposed to the same issues with the form-based implementations we’re already using, right?
Comments
You can async log it, unless, of course, the error is something in your AJAX 🙂
window.onerror would only cover a small amount of what you would want to log in a very busy client side application. There are many times a handful of different core and custom event bindings that may need to be logged as well.
Maybe we can take lessons from tracking beacons and push a log through those means. It might be more reliable to do so. Something like console.log, only safe in all streams and logs to disk. That’s just thinking off the top of my head, though.