WinJS Global Error Handling in JavaScript

In Windows Store Apps if any unhandled error comes it closes the application. This sliently happens to terminate the app. This is a default behavior. We can change this behavior by handling the “unhandled” errors.

 app.onerror = function (e) {

    var message = e.detail.message;

    var description = e.detail.description;

    var code = e.detail.number;

    var stackTrace = e.detail.stack;

    var msgBox = new Windows.UI.Popups.MessageDialog(

        description, e.detail.errorMessage

        );

    msgBox.showAsync().done();

    return true;

};

Now by saying return true

We are ensuring that application stays in the place and we continue to work. Else if we have return false then it will crash.

This behavior is not something to be tested in debug mode from Visual Studio. One should test it from the Apps list of Windows 8 desktop.

To test, put something like

 alert('1');

As alert does not work in WinJS, it will crash the app.

Namoskar!!!

Comments

• Anonymous
  February 04, 2014
  This is a really poor approach to error handling and should never be used. If you swallow random exceptions, your app will be in an undefined state and surely not be working correctly. Because you swallowed the exception you'll never get an error report from Microsoft's Watson service, and it will make it way harder to find real problems even in your own testing. Oh, and showing a bunch of error gobbledygook to your users is just going to confuse them. I haven't gotten to error handling in my blog series yet, but my advice is to only use app.onerror if you want to attempt additional logging before the app is terminated. It's very helpful when you're debugging a crash on your own self-host machines, and for tracking down issues reported by beta testers or users.

• Anonymous
  June 27, 2014
  Thanks for sharing this sample code. Its obviously is a good snippet that states a cool, poorly documented artifact of WinJS. I especially like how you did not overdue the sample, attempting into include obscure use-cases like enterprise logging, production support concerns or anything that would be so verbose it would mislead the objective of social coding. I will definitely be using this approach, mixed with my individual concerns, for future projects!