in Uncategorized

IE JavaScript Debugging near useless when try/[catch|finally] is used

As far as I can tell, IE JavaScript debuggers, such as Visual Studio or the new IE8 Developer Tool, have no ability to catch “first chance” JavaScript errors. Honestly, if I had to guess, this is probably because of some limitations of the JavaScript engine implementation more than the tools. Whatever the reason though, you run into a serious problems trying to identify where your errors are occurring if you have a try/catch/finally anywhere in the call stack.

If you just have a try/finally what happens is that the debugger will break with the current line of execution being the opening curly brace of the finally block. The entire stack where the error occurred is unrolled and you’re left with no context with which to debug:


A try/catch isn’t much better. Now the debugger won’t even break since you’ve handled the error, so you’re left having to make sure you have some sort of breakpoint or logging in all your catch blocks. What sucks even more is that the JavaScript Error class has no contextual information about the script that was executing (i.e. call stack, file name, line number, etc.). This isn’t Microsoft’s fault really, it’s just that whoever designed JavaScript thought it was important enough to have structured error handling but not to actually have any useful debugging information about the error that occurred. *sigh*

So right about now you’re probably all like “who the hell honestly uses try/[catch|finally] in JavaScript anyway”. Well, truth be told, I can’t think of a single time I’ve put it into my own code, but uhh… guess what does have it? ASP.NET AJAX. And guess where it is? Around the async callback code for the XMLHttpExecutor. Why is this such a big deal? Well, because it basically means if an exception occurs anywhere within the stack of the callback function you provide, you cannot debug it. Since one usually ends up executing a lot of code in response to ones data coming back, this is a total pain in the ass.

The good news is the latest ASP.NET AJAX previews have removed the try/finally. The bad news is that’s not RTM yet, so here are some options:

  • Debug with FireFox using FireBug. It does support first chance exceptions and will stop right where the exception occurs.
  • Plop a debugger; statement in your root callback function and step through/into the code line by line until it terminates. What sucks about this is you have to do it once to find out where it terminates and then do it again to actually avoid making the call that killed it next time so you can check out the state of things around you.
  • Pepper your source code judiciously with Sys.Debug.trace calls so you can figure out the last thing that happened before it tanked. Potentially a “good” thing anyway for tracing during testing, but definitely a pain in the ass to maintain and has a runtime performance impact that you’ll want to remove from your release mode scripts.

Leave a comment


  1. Oh, sure… no problem with the runtime here at all. It’s just that the debugger has absolutely no way to break where the error originally occurred which is pretty much what any good modern debugger offers with "first chance" exception handling.

  2. I use try/catch extensively. Without it you have no way of discovering problems in your code that you didn’t discover for yourself – bugs your users discover will remain for ever. Every line of code I write is wrapped in a try/catch block somewhere up the scope chain and in the catch block I send the error and environment details to a server script which logs to a database.The ECMAScript standard doesn’t specify the properties of the Exception object passed to the catch block. This is a serious blunder in the design of the standard, but in spite this, most browser vendors have taken it upon themselves to provide useful information in their implementations of the Exception object. Therefore the blame lies with those browser vendors who didn’t take it upon themselves to help developers by providing this much needed information in spite of the lack of standards.Opera’s Exception object is the best, because it contains a detailed scope chain which led to the error. Firefox and Safari are both good, providing the file name and line number / position of the error. Internet Explorer’s Exception object is pretty poor, providing no context about the error whatsoever. The only one that is worse is Google Chrome, which doesn’t even provide the "message" property to adequately describe the error, much less any useful debugging information.