Skip Navigation
Details
Author: Jake Howlett
Date: 13 January 2004
Article: DOMT-5UBUVW
Category: JavaScript
Hat Tip: Stephen Neal
Keywords: Debug; debugger; breakpoint; typeof; undefined;

Debugging JavaScript in Your Applications

Introduction:

Of all the languages we use on a daily basis as Domino Developers JavaScript has to be the trickiest of them all to debug. It's not necessarily that it's any harder than the other languages to debug, it's just that Internet Explorer doesn't really help us out. For example. Take this typical error dialog:

Image

The error message tells us almost nothing. After a while you start to get to know what each one might mean, but for the novice this is all but meaningless. It does provide the line number that the error happened on but trying to find this actual line is not always as easy as you might think. The line number includes all lines of JavaScript that happen to be included, as well as blank lines and whatnot.

So what do we do at this point? I sometimes find myself adding alert() boxes at strategic points in the code. You can use these prompts to tell us the values of certain variables as the code progresses. Eventually, if you're lucky, you'll discover what was causing the problem. This is no way to work though. It wastes too much time! We need to find the error fast. This article aims to describe a way of doing so.


A Simple Example:

Most JavaScript errors turn out to be really simple mistakes. Most often they are typos. Sometimes things are a lot more obscure but I will keep it simple here.

Take the form below, used for adding two numbers, as an example. Just three fields and a button:

Image

Now look at the code I wrote for the onclick event of the button. All it has to do is add the values in the first two fields and place the sum in the third:

function addThemUp(frm){
var i1 = frm.Number1.value;
var i2 = frm.Number2.value;
var fld = frm.total;

fld.value = i1 + i2;
}

Can you see my error already? Most of you probably can. For those who can't, the most valuable lesson to learn about JavaScript is that it's case-sensitive and this is the cause of endless errors. In this example I have called my field "Total" and refered to is as "frm.total" in the code. This is the cause of my "undefined" error. JavaScript looks for an object called "total" on the form and can't find it. Hence this reference is "undefined".

You might think I've spoilt the fun of describing how we go about finding the error. Well, not really - it's never fun. This article isn't a lesson in the theory of debugging. It's an article to describe the practice of debugging. Knowing how to debug effectively is something you either have or you have to pick up over the years and is well beyond the scope of this article.

Debugging the JavaScript:

The first essential step in debugging your code is getting your hands on a debugger. Microsoft give it away for free and you can get it here. Download and install a copy of Script Debugger before you carry on. You can't do much without it.

With Script Debugger installed, relaunch the browser and press the button again, you will see the same error message but a different dialog box, as below:

Image

If you click Yes the Script Debugger window will open and take you to the line of code that is causing problems.

Image

No more guessing which line it is. You know the exact line where the error occurred.

Taking it one step further:

Now that we know where the error is we can delve deeper to see what actually caused it. To do this we want to halt the code before the error and do some investigation. This is a simple case of adding the "debugger" keyword to your code, just before the line causing the error, as in the following example:

Image

When Internet Explorer encounters this line it stops executing the script and launches the debugger. This is what has happened in the above screen-shot.

Note: Browsers other than Internet Explorer will simply ignore this debugger keyword. You shouldn't worry too much about using it anyhow as it's most likely that you will only ever use it in development phase.


So, what do we do now we've paused it? Well, we need to find out exactly what it is that's undefined. To do this we can use the Command Window. From this little window you can easily check and re-assign values (at "run-time") to any of the variables that have been defined. Launch it from the View menu of the debugger or by clicking the button on the very right-hand-side of the toolbar.

To use the Command Window to check a variable's value you simply type in its name and press enter. In the shot below you can see that, one by one I've typed in the names of the variables in my function to test their values. The command window will return the value it associates with that variable on the line below. For i1 and i2 in this example you can see it contains the strings "12" and "56" but it tells us the variable called "fld" is undefined! Here lies our problem:

Command Window

Let's allow the code continue running and we can think this over. To do this you can either close the debugger or press F5. You will still see the error though! This is because fld is still undefined.

At this point you may well have that eureka moment and see the problem straight-away. If that's the case then you simply correct the code and pretend it never happened. Otherwise, we need to take this approach one step further. You can also re-assign variables from the Command Window. If you do this, then press F5 and see no errors, all is well. Once you've found the solution you can fix your code. Consider the lines in the Command Window in the screen-shot below:

Command Window

Using the typeof operator, I first check to see what it thinks the frm.total object is. As suspected, it's an undefined onject. On a hunch I try testing the typeof frm.Total, to see if I didn't give the field a capital initial. Eureka! frm.Total is an object and more than likely the field we are after. Now we can re-assign the "fld" object to point to the correct field. This is easy. All you do is type "fld = frm.Total" and press enter. Just like normal JavaScript! Test the result by testing the "typeof" of fld once more. This time it's an object. Allow the code to continue running and you shouldn't see an error. Instead you should see the total field populated with the correct value.

Trying it out for yourself:

Assuming you're using Internet Explorer and you have the the Script Debugger installed, you can test it for yourself using this form. Just click the calculate button:

This
Plus This
Equals



Summary:

Even if you already knew about and used the Microsoft Script Debugger I hope that you've found something new and useful from reading this article. It might not be the Holy Grail of script debugging but it's a basis to work on. Every situation is different and being able to debug each piece of code is something you will learn as you use it more and more.

You might be wondering how you debug script in other browsers, such as Mozilla. Well, that's a whole other ball game and probably the subject of a future accompanying article. Leave it with me.

Feedback:

Debugging JavaScript in Your Applications
. . JavaScript Errors (Tony Handscomb, Tue 13 Jan 2004)
. . . . Re: JavaScript Errors (Jake, Tue 13 Jan 2004)
. . . . . . Re: JavaScript Errors (Tony, Tue 13 Jan 2004)
. . . . . . . . Re: JavaScript Errors (David Frahm, Tue 13 Jan 2004)
. . . . . . . . . . Re: JavaScript Errors (David Frahm, Tue 13 Jan 2004)
. . . . . . . . Re: JavaScript Errors (Eva Valenta, Fri 16 Jan 2004)
. . . . How to check for undefined object in java script? (Karthik, Mon 12 Jun 2006)
. . Script Debugger vs. Script Editor (Jerry Carter, Tue 13 Jan 2004)
. . . . Re: Script Debugger vs. Script Editor (Sean McLeary, Thu 15 Jan 2004)
. . . . . . Re: Script Debugger vs. Script Editor (Pettrie, Mon 9 Feb 2004)
. . . . . . . . Re: Script Debugger vs. Script Editor (Jim Fricker, Thu 12 Feb 2004)
. . Button element (David Frahm, Tue 13 Jan 2004)
. . . . Re: Button element (Jake, Tue 13 Jan 2004)
. . Not in R5...? (Gustaf, Wed 14 Jan 2004)
. . . . Re: Not in R5...? (Jake, Wed 14 Jan 2004)
. . . . . . Re: Not in R5...? (Rob McDonagh, Tue 3 Feb 2004)
. . Something for everyone (Andy Davies, Wed 14 Jan 2004)
. . Mozilla JavaScript Debugger (harkabst_meliantrop, Mon 19 Jan 2004)
. . Access to Java with Javascript (Christian Weiss, Fri 23 Jan 2004)
. . Debugging JavaScript (Robert Lozano, Sun 25 Jan 2004)
. . JScript error handling (David Schmidt, Mon 26 Jan 2004)
. . debugger is not working as described (IanO, Tue 27 Jan 2004)
. . . . Re: debugger is not working as described (Christian Weiß, Tue 3 Feb 2004)
. . might wonder (Vec, Wed 28 Jan 2004)
. . Intermittent problems, any others? (Mike, Fri 20 Feb 2004)
. . . . Re: Intermittent problems, any others? (Duncan, Tue 24 Feb 2004)
. . Alternative to debugger; (Jim Fricker, Tue 24 Feb 2004)
. . working with commad window hangs debugger (Vlad, Fri 27 Feb 2004)
. . Debugger not allowing to debug javascript code (Suchita Desai, Mon 5 Apr 2004)
. . runtime errors (MELINDA EDWARDS, Thu 26 May 2005)
. . . . Re: runtime errors (Hari Prasad, Thu 16 Jun 2005)
. . Runtime error (habeeb, Mon 21 Nov 2005)
. . runtime error (Char, Wed 23 Aug 2006)
. . it is so usefull (sathiya, Wed 7 Feb 2007)
. . very good article (binoy, Thu 12 Apr 2007)
. . . . Re: very good article (hari, Fri 16 May 2008)
. . good (Narender, Mon 20 Aug 2007)
. . . . Try Firebug! (Jeroen Brattinga, Mon 26 Nov 2007)
. . Thank you (PCJIM, Thu 24 Jul 2008)
. . Thank you, a very nice article (Rohit, Wed 15 Oct 2008)

Add your response here:

Name *:
Email:
Protected from spambots!
Remember My Details
Subject *:
Message:
HTML is not allowed and Passthru is disabled!
*=required