Graceful Handling Of JavaScript Errors

Introduction

In this small article, we would discuss how to gracefully handle JavaScript errors, instead of the browser dependant behavior of pointing out the errors to the visitor, who does not know much, how to deal or remedy that error. This would also facilitate us to communicate to the server that a client side script has failed and one or more of client-script manipulations might not have completed successfully and that the server needs to check those functionality again at its end.

The Scenario

JavaScript has got pretty embedded nowadays with every web page -- ranging from cosmetic and flashy document effects to user-form entry checking/confirmation etc. Perhaps if there is a client side scripting error, due to unforeseen circumstances, it would be disgusting to the user to see a 'Done but with errors on page' flashing on the window status bar. When a scripting error occurs, normally the running script function is also halted by the web browser and no further script calls are executed in that context. Perhaps, in these cases, it would be good if our script could notify back the server of its failure and also to gracefully report the error/failure condition to the user.

The Solution

The solution to the above-said problem is quite simple and straightforward and can be solved in multiple tiers, depending on the need and complexity of the scripting, and the page functionality itself.

• Catch and Intimate User In A Friendly Way

  In the starting of the webpage, just append the following lines:

  window.onerror = errorHandler;
  
  function errorHandler(msg,url,lno)
  {
    var alertmsg = "There has been an internal error." + 
                   " Please apologize for inconvenience.";
    alertmsg += "\n\nPlease refresh this page and this error should go away.\n\n";
    alertmsg += "If problem persists please contact site helpdesk.";
    alert (alertmsg);
    return (true);
  }

  Perhaps you can extend this by opening a small custom window and displaying the error in a more friendly fashion.

• Intimate Server Back

  Frameworks and environments like .NET have easier PostBack functionality, that you can make use of effectively to deal with this kind of situations. When an error occurs, you can manually call __doPostBack(). Perhaps this function would be available only when there is a PostBack enabled control in the webpage like DataGrid, Checkbox/Dropdownlist with AutoPostBack=true. We can effectively circumvent this issue, by having a dummy LinkButton with no text. This will force .NET runtime to define the __doPostBack function and we can pass error details to the dummy LinkButton Handler.

Conclusion

Whatever is the trick above, that we are using, the objective is that the visiting user is not disturbed by showing a message that a script error like 'Object Expected' has occurred to the user, who does not know what 'Object' the browser is expecting. Isn't it? I hope that the article would be a great help to Internet Application Developers worldwide to enable their applications handle client-side scripting errors gracefully.

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here