Skip to content

How to debug Javascript

by arlo on February 4th, 2011 

NOTE: This is a remedial technique and not something to use on large scale or collaborative javascript applications

For the past year I have been writing, maintaining and fixing a javascript API for my employer. When bugs arise I frequently have had a hard time debugging the situation. Granted, I am new to the javascript application development world, I would like to share my debugging process to those who might find themselves in the same.

To alert() or not to alert()

The novice move is to start alert()-ing your variables and object properties to see their state. Though this technique worked at first, it still felt somewhat barbaric and cavemanish.  My first problem with alerts is that only in Firefox was I able to copy the contents of an alert.  Why do you need to copy the contents of an alert?  When calling 3rd party data providers and parsing server responses, from time to time I needed to validate certain data in a separate data source (database).  This became a problem since I prefer not to be bound to a single browser and most of the time I was fixing bugs in IE.

.....
function(){
     alert("I have entered this function.");

     // Random IF statement
     if( api_is_loaded )
     {
          alert("API is loaded.");
          // Code goes here
     }else
     {
          alert("API is not loaded.");
     }

     // Lame Caveman Joke
     alert("Me want debug......me get debug....");
}
...

Worst problem with the alert approach is that you need to go back and erase ALL your alerts after you have figured out your error. You don’t want your user’s seeing random alerts here and there and it becomes common to over see an alert() or two before committing into production server. (Oops!) Alerts are also not recommended in loops. It is not acceptable to click OK 50 times during a debugging process.  I quickly concluded that alerts had to go and they should no longer play a role in  my debugging experience.

The Console API

Firefox, Chrome and IE 8 have an existing console object in the global scope and you can also add it to other browsers via  firebug lite. The console API functions I use the most are console.log(), console.warn() and console.error(). You can also learn how to create groups and trees in the Firefox console API.

With log(), warn() and error() you can effectively keep track of how your application is being executed, which functions are being called and what state your variables are in. Below is a screen shot of what my development and debugging process looks like as I sift through my javascript API.

Object Debugging

You may note in the above picture a log entry that lists a object’s attributes. This type of debugging is most useful for knowing what object attributes and methods are available for use. You can accomplish object debugging by passing the object to the console.log() method.

console.log( document );

The above line with build a tree in the browser console that lists all the attributes and methods of the document API. You can see the above code in action at jsconsole.com.

Unobtrusive Console API

One of the first problems I faced with using the console API was cross browser compatibility. As I mentioned in the beginning of this post, only a handfull of browsers have a console API in global scope. This created a huge problem when I decided to litter my javascript API with console logs in an effort to pinpoint a huge glitch. Once I pinpointed my programmatic error (thanks to console API) I decided to check the web app in IE 7 and was bombarded by JS exceptions. Console object is undefined. I didn’t feel that I should go back and erase 50+ lines of console.log(). Mostly because it doesn’t make sense to log application activity only while fixing bugs. Debug information is just as useful while developing than it is while you fix bugs. I decided to take a very common approach to this problem.

var console = console || {
     log:function(){},
     warn:function(){},
     error:function(){}
};

Ureka! In a mere 5 lines of code you have made your debug log unobtrusive. If a certain browser does not have a global console object, then “console” is assigned an object literal that contains log(), warn() and error(). No more exceptions will be thrown on lower grade browsers and you can leave your console calls in your javascript application. I hope this post is useful in your javascript application. Happy debugging!

NOTE: This is a remedial technique and not something to use on large scale or collaborative javascript applications

From → Javascript

  • Pingback: Debugging Javascript using the Brower’s Console

  • Buster Highmann

    HOLY FUCKING SHIT CONSOLE.

  • Donavan Stanley

    Internet Explorer actually has a rather nice javascript debugger built into it.  Trace debugging should be a last resort.

  • http://www.arlocarreon.com Arlo Carreon

    very true. for browser specific bug finding a debugger is the way to go

  • Pingback: console.log() and Internet Explorer | Mike Funk

  • Greg Silcox

    Thanks Arlo, I find this quite helpful.

  • http://www.arlocarreon.com Arlo Carreon

    Awesome!