I was following a thread recently where a dev was trying to track down an app crash. In this case he had a window.onerror handler set up but it wasn’t being called.

The bottom line in the thread was that if any exception is thrown within the context of a WinJS.Application event, such as onactivated, then it will be picked up only by a WinJS.Application.onerror handler and not window.onerror. On the other hand, exceptions that are thrown in any other function context, e.g. the callback to a setTimeout or a button click handler, will be picked up by window.onerror as well as by WinJS.Application.onerror, which wraps window.onerror.

Consider the following bit of code in an otherwise blank app project:

(function () {
​   
var app = WinJS.Application;

​   
app.onactivated = function (args) {
​      
throw (“Error from on activated”);
    };

    app.onerror = function (e) {
        console.log(“WinJS.Application.onerror e = “ + e.detail.errorMessage);
        returntrue;
    }

    window.onerror = function (e) {
​       
console.log(“window.onerror e = “ + e)
        returntrue;
​   
}

    app.start();

    throw (“Error outside of WinJS.Application.”);
})();

Running this code, Visual Studio will call out the exception from the last throw. Pressing Continue you’ll get to window.onerror, followed by app.onerror. You’ll then get into app.onactivated, where that thrown exception will then take you to app.onerror but not window.onerror.


2 Comments

  1. Josh
    Posted November 24, 2013 at 1:26 am | Permalink

    Yes. If you are using the app model then the only error handler you should bother with is the app model one.

  2. Posted November 27, 2013 at 7:14 am | Permalink

    Best to have both error handlers: despite how robust one’s code is, I think one will be surprised at what one sees.
    Another good post on this: http://palermo4.com/post/JavaScript-for-Windows-Store-Apps-Error-Handling.aspx