Dsawiki: JavaScript Debugging Tips

Note#

Mostly taken from http://www.sitepen.com/blog/2008/04/03/advanced-javascript-debugging-techniques/

Tips#

Preventative Tips#

Refresh Often#

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.

Copy/Revert#

General Debugging#

JSLint#

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.

Numbered log messages#

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.

Comment out code#

Comment out large chunks of code to isolate the problem.

Talk About It#

Walk Away#

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 dojo.data stores. I use dojo.mixin({}, myObject) to make sure the object logged is in the right state.

Tweak Apache Cache Settings#

Tweak your Apache settings so that javascript files are not cached. This htaccess snippet will give files ending in .js a maximum age of ten seconds:

Header set Cache-Control “max-age=10″

It can be really annoying to have to clear your cache every time you make a change.

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 debugging#

dojo/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: foo.prototype.bar = 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" <mike@foo.com>, "Tom Trenka" <tom@foo.com>'
.match(/(['"])([^'"]*)\1/g)

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 Lite#

Firebug 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 Headers#

HTTP 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).

URLs#

Software#

JSLint
Firebug Lite
Debug Bar
Fiddler
Live HTTP Headers, works on Mac
Web Development Helper
Internet Explorer Developer Toolbar
Charles is a more powerful version of Fiddler, but it’s also available for OSX and Linux

Table of Contents