window.onerror – custom error handling

Listen to colleagues, even or especially if they are not in your department as something useful may come out as a result.

This is more of a cultural phenomenon than a real development topic, but can be drilled down to a nice real-world example that’s currently taking place here at XING. It started with a small discussion (shortened of course) between a frontend developer (FE) and a quality assurance engineer (QA).

(We’ll leave the discussion there)

After that little chat we decided to take a previously used approach for collecting anonymous information about JS errors. window.onerror (which every major browser has implemented) is overwritten in a development environment by some native code that fetches the message, line number and path of the error object and prints it into a new element on the page. This “container” appears in a fixed position so that you can see it everywhere and not just when scrolled to the top (of course only in browsers that support this).

Pros

- Fast and easy to report
- You immediately see the bug without having to search for it… ;)
- More precise error reports
- Just one hour’s work results in:
– less time needed for bug searching
– less time needed for bug reproducing
– less time needed for bug reporting
– and even less time needed for bug fixing

Cons

- No access to the stack in window.onerror
- Requires additional handling
- May ONLY be delivered in development ;)

Conclusion

From a technical perspective this is a huge step although only a small piece of work is required, and therefore glues two departments together in cultural terms.

One week later: Déjà vu…

About the author

12 thoughts on “window.onerror – custom error handling”

1. In some browsers you can also get the stack. Just trigger and catch an exception in your onerror Function:

   window.onerror = function() {
   var trace;
   try {
   throw new Exception;
   } catch (ex) {
   trace = ex.trace; // works in chrome
   // depending on browser could also be another property or function
   }

   // continue with processing of arguments and trace
   };

2. Hi Robert,

   I tried to use what you pasted here in a small test site. At least not working for me. I built up a method chain with an unexisting method at the end. When triggering that on the site the trace property is empty (tested in Chrome 20.0.1132.47 and Firefox 13.0.1) or to be precise console.log(trace); shows undefined.

   Using ex.stack works in Chrome for a real try / catch statement but not in window.onerror. In current Firefox (13.0.1) ex.stack contains the stacktrace in both cases. As far as I know this is due to the fact that onerror is called in another context. See also: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Error/Stack

   Could you paste a working jsfiddle? :) I am eager to see how the trace property might work and how to use it.

   Cheers,
   Tobias

3. Not even Firefox 13.0.1 shows the expected stack (when trying to retrieve it in window.onerror). It shows the window.onerror stacktrace which is not what we want to use. :(

   Cheers,
   Tobias

4. I assume that almost every javascript error happens after user interaction (eg. a click, mouseover, keyup, …).
   For such cases jQuery has a single point you can hook into, to get much more information about the error itself (stack trace) and how it evolved (event object).

   Something like this might work (untested):
   https://gist.github.com/de9ff9ae537e80909e1b

   Please note: This can slow down script execution and make debugging in development environment harder … but still might be worth a try.

5. Interesting idea. =) Will play around with that.

   Many thanks.

6. @tiff is $.event.dispatch triggered onload, ondomready etc.?
   Some JS errors already in the rendered page (think of invalid JSON rendered into the page, or errors on initializing events). Of course it would be nice to catch those as well.

7. For stacktraces, you might want to use https://github.com/eriwen/javascript-stacktrace.

   And window.onerror is great! I also use it for BetterExamples.js to show any error at the JS line that produced the error. Very visual :-) See http://willemmulder.github.com/BetterExamples.js/

8. @Phillip:
   onload: yes
   ondromready: no (you’d have to override $.event.trigger for this since this event is handled a bit differently)

   There will always be exceptions that won’t be catched by this approach.
   I’d go with a combination of window.onerror and $.event.dispatch.

   Must say haven’t tried this yet.

9. Thanks guys.

10. Btw. this page shows a JS error: SyntaxError: Unexpected token & [https://www.xing.com/connect/databridge?site_key=534f418d:11]

11. @Phillip:
    Thanks. We already know about the problem and will solve it soon.

12. Phillip looks like you have too much time :D