Logging JavaScript errors to a WebService

Victor van Hagen (a collegue of mine at Macaw) has build a nice logging feature into the web application we're building together at the moment. This logging feature takes care of logging client-side JavaScript errors to a special 'Logging' WebService!
This way you're able to monitor the JavaScript errors that occur on the browsers of your clients. Pretty powerful tool to improve your application!

The solution is very simple:

  • create a HTML-element that's able to call WebServices (using the free available 'webservice.htc' html component by Microsoft)
  • implement the window.onerror, and set this to your own 'logError' javascript function
  • inside your 'logError' function, call the logging WebService and send it all error information (and also some information about the client's browser)
  • on the 'onresult' event, display a message in the statusbar, informing the user that the error was logged.

Now let's take a look at the code (I've simplified our original code a bit, so it's easier for you to read and understand).
First I'll show you the html page that throws a client-side error, catches it using windows.onerror, and posts it to a logging WebService. Second I'll show you the C# code of the logging WebService (to keep the code simple, the actual logging is left out here).
Note: you can download the webservice.htc code at:
http://msdn.microsoft.com/archive/en-us/samples/internet/behaviors/library/webservice/webservice.htc.

ClientExceptionLogging.htm:

<html>

  <head>

    <title>Client Exception Logging testpage</title>

  </head>

  <body>

    <div id="logService" style="behavior:url(webservice.htc)"

      onresult="window.status='Error logged as LogEnty#' + event.result.value"></div>

    <script language="javascript">

      function logError(sMsg, sUrl, sLine) {

        try {

          logService.useService("ClientExceptionLogger.asmx?WSDL", "Logger");

          logService.Logger.callService("Log", sMsg, sUrl, sLine,

            navigator.appName, navigator.appVersion);

          } catch(e) {}

        return false; //re-throw error

      }

      window.onerror = logError;

    </script>

    <button onclick="blabla.whatever = 3;">Throw an error</button>

  </body>

</html>

ClientExceptionLogger.asmx.cs:

namespace ClientExceptionLogging

{

  public class ClientExceptionLogger : System.Web.Services.WebService

  {

    [System.Web.Services.WebMethod]

    public int Log(

      string msg,

      string url,

      string sLine,

      string navigatorAppName,

      string navigatorAppVersion)

    {

      //TODO: do your logging here (I prefer Log4NET at the moment)

 

      //for testing purposes: return fake LogEntry ID

      return new System.Random().Next(int.MaxValue);

    }

  }

}

6 Comments

  • My application has had client side javascript error logging for years.



    It is valuable but you will end up with a ton of false positives. You need to make sure you can tie the errors to a user.



    1. Spyware

    Many errors you will see will actually be because of some spyware that the user has installed (They interfere with javascript and cause errors). Our customer support department call users and walks them through removing the errors and voila!, the errors are gone. We picked up on this because users that had a spyware product installed, kept getting similar errors.



    2. Slow internet connections. When including script libraries, the page will load buttons dependent on those libraries first causing an error. We had to rearchitect our app to ensure that script libraries were all loaded before. In asp net you'll get a lot of false positives because of its dependence on the asp.net js files. The code asp.net generates simply doesn't check to make sure that library is completely loaded before referencing functions in it. You can't count on those files being cached by the client browser either.



    3. There will be errors that you see in which you won't be able to reproduce. We've had clients on the phone, doing exactly what they do, they get the error we don't. Same OS, same service packs. Typically, if we have them reinstall IE it takes care of it. Sometimes they gone as far as reinstall their operating system to fix the problem. (BTW, I'm not a fan of firefox, but you got love how a corrupted version can be fixed in just a few minutes, by uninstalling and reinstalling.)



    The best lesson I would say we learned from logging javascript errors is the following, If you need to fix an error in one of your js files, you absolutely MUST rename in. Many users, especially those behind a poorly configured corporate PROXY server, will not get new js files, no matter how the client is configured. We put the version of the js file in its name to avoid this pitfall.



    -JC







  • A solution that's only IE! That's sooo 90s...

  • You should make sure you are trapping for line#0.



    So if someone goes to their address bar and types: javascript:foo.bar();



    You don't log it as an error.

  • Why build your own? There is a website that offers this service professionally (and it works in all browsers) ==&gt; elog.com

  • I have just released code to help log JavaScript errors by sending error information to the server -
    http://www.thecodepage.com/post/JavaScript-Error-Notifications.aspx

  • I have just released code to help log JavaScript errors by sending error information to the server -
    http://www.thecodepage.com/post/JavaScript-Error-Notifications.aspx

Comments have been disabled for this content.