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.