How can we listen for errors that do not trigger window.onerror?
window.onerror is triggered whether it was a syntax or runtime error. This page from quirksmode has lists of what error events it will and will not catch.
Could you please provide a small code example to show how we can listen for such errors? Can we listen for SyntaxError too?
For a small code example to show how we can listen for such errors:
<!DOCTYPE html>
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<script type="text/javascript">
window.onerror = function (errorMsg, url, lineNumber) {
alert(errorMsg + lineNumber);
// alert("This is a stack trace! Wow! --> %s", error.stack);
};
</script>
</head>
<body>
<script type="text/javascript">
//var x=document.getElementById("demo").value; //uncomment and run to see
document.write('careless to close the parentheses?'; // ')' is not given
</script>
</body>
</html>running this example in your browser will pop up an alert message similar to this:
JavaScript error: SyntaxError: missing ) after argument list on line 26 for page_url
In the above example: window.onerror = function(message, url, linenumber), the arguments are:
message: the error message (DOMString)url: the URL of the file containing the error (DOMString)linenumber: the line number where the error occurred (unsigned long)
If you run the same example by putting var x=document.getElementById("demo").value; instead of the code with syntax error(as i have shown in the example), it will also be caught by the window.onerror() function and will show an alert message similar to this:
JavaScript error: TypeError: document.getElementById(...) is null on line 25 for page_url
window.onerror acts something like a global try/catch block, allowing you to gracefully handle(even with server logging) uncaught exceptions you didn’t expect to see:
-
uncaught exceptions
throw "some messages"call_something_undefined();cross_origin_iframe.contentWindow.document;, a security exception
-
some more compile error
<script>{</script><script>for(;)</script><script>"oops</script>setTimeout("{", 10);, it will attempt to compile the first argument as a script
But two major issues described here nicely:
-
Unlike a local try/catch block, the window.onerror handler doesn’t have direct access to the exception object, and is executed in the global context rather than locally where the error occurred. That means that developers don’t have access to a call stack, and can’t build a call stack themselves by walking up the chain of a method’s callers.
-
Browsers go to great lengths to sanitize the data provided to the handler in order to prevent unintentional data leakage from cross-origin scripts. If you host your JavaScript on a CDN (as you ought), you’ll get “Script error.”, “”, and 0 in the above handler. That’s not particularly helpful.
