Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How can we listen for errors that do not trigger window.onerror?

Tags:

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers.onerror states:

Note that some/many error events do not trigger window.onerror, you have to listen for them specifically.

  1. Could you please provide some examples of errors that do not trigger window.onerror? I know SyntaxError is one of them.
  2. Could you please provide a small code example to show how we can listen for such errors? Can we listen for SyntaxError too?
like image 549
Lone Learner Avatar asked Oct 02 '13 15:10

Lone Learner


People also ask

How does Onerror work?

The onerror event is triggered if an error occurs while loading an external file (e.g. a document or an image). Tip: When used on audio/video media, related events that occurs when there is some kind of disturbance to the media loading process, are: onabort. onemptied.

What is window Onerror?

Introduction. onerror is a DOM event handler. It is started when an error occurs during object loading. While window. onerror is an event handler, there is no error event being fired: instead, when there is an uncaught exception or compile-time error, the window.

What are the three information provided by Onerror () method?

The Error object and error. It contains 3 standardized properties: message, fileName, and lineNumber. Redundant values that already provided to you via window. onerror .

What does Onerror mean?

The onerror attribute fires when an error occurs while loading an external file (e.g. a document or an image).


1 Answers

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:

  1. message: the error message (DOMString)
  2. url: the URL of the file containing the error (DOMString)
  3. 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

    1. throw "some messages"
    2. call_something_undefined();
    3. cross_origin_iframe.contentWindow.document;, a security exception
  • some more compile error

    1. <script>{</script>
    2. <script>for(;)</script>
    3. <script>"oops</script>
    4. setTimeout("{", 10);, it will attempt to compile the first argument as a script

But two major issues described here nicely:

  1. 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.

  2. 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.

like image 110
Sage Avatar answered Oct 19 '22 12:10

Sage