Your wonderful one-of-a-kind web application just had a successful launch and your user base is rapidly growing. To keep your customers satisfied, you have to know what issues they face and address those as fast as possible.
One way to do that could be being reactive and waiting for them to call in – however, most customers won’t do this; they might just stop using your app. On the flip side, you could be proactive and log errors as soon as they occur in the browser to help roll out fixes.
But first, what error kinds exist in the browser?
Errors
There are two kinds of errors in JavaScript: runtime errors which have the window object as their target and then resource errors which have the source element as the target.
Since errors are events, you can catch them by using the addEventListener methods with the appropriate target (window or sourceElement). The WHATWG standard also provides onerror methods for both cases that you can use to grab errors.
Detecting Errors
One of JavaScript’s strengths (and also a source of much trouble too) is its flexibility. In this case, it’s possible to write wrappers around the default onerror handlers or even override them to instrument error logging automation.
Thus, these can serve as entry points for logging to external monitors or even sending messages to other application handlers.
//logger is error logger
var original = window.onerror; //if you still need a handle to this
window.onerror = function(message,source,lineNo,columnNo,errObject){
logger.log('error', {
message: message,
stack: errObject && errObject.stack
});
original() //if you want to log the original
return;
}
var elemOriginal = element.onerror;
element.onerror = function(event) {
logger.log('error', {
message: event.message,
stack: event.error.stack
});
elemOriginal();
return;
}
The Error Object
The interface for this contains the error message and optional values: fileName and lineNumber. However, the most important part of this is the stack which provides information about the stack.
Note: Stack traces vary from browser to browser as there exists no formatting standard.
Browser compatibility woes
Nope, you ain’t getting away from this one.
Not all browsers pass in the errorObject (the 5th parameter) to the window.onerror function. Arguably, this is the most important parameter since it provides the most information.
Currently the only big 5 browser that doesn’t pass in this parameter is the Edge browser – cue the only ‘edge’ case. Safari finally added support in June.
The good news though is there is a workaround! Hurray! Let’s go get our stack again.
window.addEventListener('error', function(errorEvent) {
logger.log('error', {
message: event.message,
stack: event.error.stack
});
});
And that wraps it up! You now have a way to track errors when they happen in production. Happier customers, happier you.
Note: The eventListener and window.onError approaches might need to be used in tandem to ensure enough coverage across browsers. Also the error events caught in the listener will still propagate to the onError handler so you might want to filter out duplicated events or cancel the default handlers.
Related
Tips for printing from web applications
Liked this article? Please share, subscribe or drop a comment.
