Advanced JavaScript Debugging Techniques

By on April 3, 2008 1:53 pm

The purpose of this article is to provide a list of advanced debugging techniques that are not easily found elsewhere on the web. Using Google to search for JavaScript debugging just gives you hundreds of articles about using alerts and how Firebug works. We all worship at the altar of Firebug, but there are things that can go beyond a console.log(). The following is a list of methods that every developer should have in their toolbox.

Preventative Tips

Refresh Often – As most web programmers have figured out, the more edits you make to your script the greater the chance of error. The area where those errors can occur also widens exponentially. Try to keep your edits to one script block at a time and test.

Multiple Undo – If your IDE supports it, jack up your undo/history to at least 100 levels. This can be a lifesaver when your edits just seemed to break everything and your money ahead by backing them out and starting over.

Copy/Revert – Before you back out the changes of an extensive but bad edit, copy the whole script and paste it into a new file, then undo your code to the original state. You can then reintroduce the new edits a little at a time to isolate where the error occurs.

General Debugging

JSLint – Don’t be a hero. Copy and paste the script into JSLint. Not only will this do a great job of finding the cause of your error, it will also point out some bad programming habits and accidental globals (not using var) and show you all of your missing semi-colons.

Price is Right – Insert numbered log messages console.log(1), console.log(2), etc. into various areas of your code to narrow down the area with the problem. Keep adding more logs on different lines with higher and lower numbers (get it?), using 1.5, 1.73, whatever, until you key in on the line that’s the problem. This is similar to using break points, but gives you a different look.

Take Away – Comment out large chunks of code to isolate the problem. I’ve gone so far as to disable the entire app and reintroduce the code a little at a time from the beginning. Consider this a very broad Price is Right technique.

Talk About It – I can’t even say how many times this has worked: before I even finish describing the problem to a coworker… I get the “AH HA” moment.

Walk Away – Sometimes you need to walk away and clear your head. Take a break. Maybe put the code aside and sleep on the problem and revisit it the next day. This really works wonders, as it releases the tension in your brain and allows it to solve the problem in a different, more relaxed state.

Google It – While this is fairly obvious, if the problem can be described simply you can search for it. This doesn’t work so well if it’s complex, or if you have a problem like “args has no properties”. But it does work if you encounter something obscure such as “No such interface supported”.

Snapshot of Object – Although usually not the case, sometimes the object changes from the time Firebug logged it to the time you look at it. I’ve witnessed this problem in stores. I use dojo.mixin({}, myObject) to make sure the object logged is in the right state.

IE Debugging

IE Silently Fails – Arguably, this is the biggest annoyance of IE—the page just doesn’t load and doesn’t give any errors. Sometimes you need to view the page again in Firefox. If it’s not an IE specific error, Firebug will pick it up. If Firebug loads normally, the chances are it’s one of two IE specific errors: a trailing comma, or unsupported XML syntax.

JSLint Again – JSLint will pick up code that is a problem for IE but not necessarily for Firefox.

Trailing commas – Search your script for: ,} and ,] (allowing for line breaks, tabs, and white space, etc.). This will catch the infamous “trailing comma” problem that fails silently in IE but not in Firefox.

MS Script Editor Inconsistencies – I’ve found that sometimes IE just notifies you of an error without giving you the option to debug the script. This seems to be session based—if you close the page and reopen it, it will give you the option to debug—that is, if you have its cryptic debug settings properly configured.

XML – Where to start! There are many XML differences between IE and Firefox. I believe most of IE’s XML functionality works in Firefox. So in short, whenever working in XML, make no assumptions that it will work in IE without checking.

Break Point Debugging

Step-Wise Debugging – For logic errors, there’s sometimes no substitute for peppering break points around likely-looking places, and walking through line-by-line, function by function—in Firebug/Venkman/MSE/Visual Studio—all of which support stepwise debugging.

Dojo Toolkit-specific tips for stepwise debuggingdojo/event and dojo/method blocks are very difficult to work with in the debugger. Also, if you can avoid going down the intricacies of dojo.declare (object instantiation) when you are debugging, you’ll save on valuable sanity best applied elsewhere—step out whenever you hit it. The same goes for dojo.connect—you are best off putting a break point in the function you are connecting to, rather than stepping into the connect invocation.

The Step Through – You can set watches to see expressions evaluated at each point, but you can also use the console to craft your own expressions—with the Dojo Toolkit at your disposal there, there’s not much you can’t do mid-flow to really get a picture of what’s going on. Have a file of snippets handy for pasting into the console for each project—like to check a particular property on all widgets.

Dojo Toolkit Specific Debugging

Include Dojo files – Try setting debugAtAllCosts to true in djConfig. This didn’t work for a little while during the Dojo 0.9 period, but it’s working quite well now with the exception of a few fringe cases. The dojo.loader uses XHR to load script files and initializes them with eval. This unfortunately confuses the debuggers and thinks all errors occur within the dojo.loader. debugAtAllCosts tells the dojo.loader to attach all the scripts traditionally in the head of your document, where debuggers will have an easier time pinpointing the problem area.

Syntax Catcher ‘Beta’ – I’ve submitted code to the Dojo Toolkit that detects if a file has an error on load, such as a typo, missing bracket, etc. This is enormously helpful, especially if you’re a fast, sloppy typist; it saves you the trouble of reloading with debugAtAllCosts or visiting JSLint just to find an incorrect character. Unfortunately, there are still a few problems getting it to work with IE. But you can use it in your personal copy of the Dojo Toolkit by grabbing the latest syntax catcher code.

Firebug Tips

Firebug Documentation – Make sure to read both the command line API and console API in Firebug’s docs. They allow you to do some pretty crazy things beyond just logging.

Command Line

Real Time Editing – Editing code in real time sure beats waiting for things to go to staging. Basically, use whatever console is available (and at this point, you can do this in any browser—see the tools below) and replace the function with modified code. This would look something like: = function(){}. It also allows you to work on code without having to refresh the page. If you’re working with the Dojo Toolkit, you can even use dojo.require to load a file or a package and work with it right there.

Expressions Testing – Use the console command line to directly test your expressions. This example pulls names out of email contacts:

'"Mike Wilcox" , "Tom Trenka" '

Open the console in Firebug and paste in that example and click ‘Run’. This works great with the date object too, and testing its myriad methods.

Debugging Tools

Firebug LiteFirebug Lite works in IE and other browsers, and if you’re using the Dojo Toolkit it comes included, with some enhancements like launching in a separate window, and an object inspector. And of course there’s Firebug itself, but you knew that.

Debug Bar – Debug Bar Core Services has released Debug Bar, a Firebug equivalant for IE. Great inspectors for the DOM, HTTP, script and style sheets. Plus it provides you with much needed IE error handling. It has a JS command line, but in spite of its claims, it seems to be lacking any actual logging.

Fiddler Fiddler is a very robust proxy that logs your HTTP calls. More information than you’ll ever need. Claims to work all browsers, but it uses the .NET Framework, so it’s Windows only.

HTTP Live HeadersHTTP Live Headers works on a Mac, and captures all of your HTTP calls.

Web Development Helper – Another Firebug equivalent for IE, Web Development Helper is a pretty nice little app, with many of the same features as Debug Bar, except that it’s free, and it actually has a logging feature, although it’s plain text. A lot of the information appears in pop-up windows, which hurts persistence. It has an object inspector, but that too is in a window. However, this is definitely worth a look.

Internet Explorer Developer Toolbar – Microsoft’s Internet Explorer Developer Toolbar is certainly an improvement over what it had before. A lot of inspectors and shortcuts to useful features like cache clearing (which now takes two clicks instead four).

Debugging Links

The Dojo Book – Debugging JavaScript

An In-depth Look At The Future of Javascript Debugging With Firebug

HOW-TO: Debug JavaScript in Internet Explorer

IE Blog – AJAX Experience & Tools

This list of debugging techniques came about as a collaborative effort from other members of the SitePen team besides myself. Contributors to this list include: Kris Zyp, Neil Roberts, Sam Foster, Joe Walker, Tom Trenka, and Dylan Schiemann.

Are there some good tricks that have been left out of this list? Continue the collaborative effort and post them in the comments.