Once you find a
bug, you can get rid of it. Unfortunately, finding the suckers isn't
always easy — most of your debugging time is spent just figuring out the
location of the error.
One of the most tried-and-true debugging
methods is to put
simple statements in your code that print out what's
going on. Let's
say you're having a problem with these two
functions:
function getName()
{
var first_name = prompt("what's your first name?","");
var last_name = prompt("what's your last name?","");
var the_name = first_name + " " + last_name;
}
function theGreeting()
{
var the_name = "";
the_name = getName();
if (the_name == "Dave Thau")
{
alert("Hello, oh greatest one!");
} else {
alert("Ahoy palloi!");
}
}
Give
this example a try and see if you can figure out what's wrong (Netscape 3.x users may experience some error check problems due to the nature of this, and the following Javascript examples). If you enter random names into the alert boxes, you get the greeting "Ahoy palloi!" However, if you enter "Dave" in the first prompt box and "Thau" in the second, you're supposed to get the message "Hello, oh greatest one!" Instead, you still get the "Ahoy palloi!" message. Obviously, something's wrong with the functions. In this simple example, you could probably find the errors just by looking at the JavaScript. However, as your scripts get more and more complicated, finding your errors just by eyeballing them grows increasingly difficult.
If JavaScript doesn't catch your error, and you can't
figure it out just by looking at your script, it sometimes helps to print
out variables. The easiest way to do this is with an alert(), like
this:
// theGreeting gets a name using getName, then presents one or two
// alert boxes depending on what the name is
//
function getName()
{
var first_name = prompt("what's your first name?","");
var last_name = prompt("what's your last name?","");
var the_name = first_name + " " + last_name;
alert("in getName, the_name is: " + the_name);
}
// theGreeting gets a name using getName, then presents
// one of two alert boxes depending on what the name is
//
function theGreeting()
{
var the_name = "";
the_name = getName();
alert("after getName, the_name = " + the_name);
if (the_name == "Dave Thau")
{
alert("hello, oh greatest one!");
} else {
alert("ahoy palloi!");
}
}
Notice we've placed alerts at
all the important points. Now try the version with lots of alert boxes. If
you enter the names "Dave" and "Thau," you'll notice that the first alert
says "in getName, the_name is: Dave Thau,"
but the second alert says
"after getName, the_name = undefined,"
which tells you things got messed
up right after the last line of getName().
Somehow,
the_name is OK just before the function exits, but
theGreeting doesn't correctly set the variable the_name.
When you've written a function that does the right thing, but has problems
returning a value, the first thing you should check is whether you're
actually returning the value. And sure enough, that's the problem here.
The getName() function figures out the name, but never returns it.
So we need to add
return the_name;
at the end of the
function.
Putting a bunch of alert boxes in your code is very
helpful. Unfortunately, hitting "OK" every other line is also sort of a
pain.
You can do a few things to debug your code without the hassle of the alert box. One option is to write your debugging messages to a text area inside a form. Another possibility is to write the debugging messages to another window. Here's an example of debugging code that writes debugging messages to the text area below.
A third trick that can make your debugging experience more pleasant involves creating different debugging levels and then setting a "debug" variable. Here's the JavaScript that actually runs on this page:
// debug can be either none, alert, or textarea depending
// on the kind of debugging I want to do
//
var debug = "none";
// function getName gets a first and last name, concatenates
// them with a space in between, and returns the name
//
function getName()
{
var first_name = prompt("what's your first name?","");
var last_name = prompt("what's your last name?","");
var the_name = first_name + " " + last_name;
var error_message = "in getName, the_name is: " + the_name;
doError("in getName, the_name is: " + the_name);
}
// theGreeting gets a name using getName, then presents
// one of two alert boxes depending on what the name is
//
function theGreeting()
{
var the_name = "";
the_name = getName();
doError("after getName, the_name = " + the_name);
if (the_name == "Dave Thau")
{
alert("hello, oh greatest one!");
} else {
alert("ahoy palloi!");
}
}
// doError is the error handling routine
// depending on the type of debug message
// it presents either no debug message, an alert
// or puts the message in a textarea
//
function doError(the_message)
{
if (debug == "alert")
{
alert(the_message);
} else if (debug == "textarea") {
window.document.the_form.the_text.value += the_message + "<br>\n";
}
}
Notice that I've defined a variable called "debug" that can be either "none," "alert," or
"textarea." Then when I want to generate an error message, I send it to the function doError(), which either does nothing, presents an alert box with the message, or sticks the message in a text area, depending on how I set the debug variable. You can set the debug variable to "textarea," when you have lots of errors that you want to look at simultaneously. Then, when you're ready to show your code to the world, you can just set debug to "none," and the error message will no longer show up, which saves you the hassle of having to find and remove all your debug statements.
Often, programmers create different debug levels, such as "none," "brief," and "extreme." "Brief" will print a few debug messages along the way, "extreme" will print a lot of debugging messages, and "none" will of course print no messages.
If you build your debugging system like this, you can set the debug level to "brief" while you're coding, and "none" when you're ready to make your JavaScript public. Then, if something totally weird starts happening, and you don't know where to look for the
problem, you can set the debug level to "extreme" and wade through all the debug messages until you find something suspicious.
OK, enough about debugging systems. Let's turn now to common mistakes made by JavaScript coders.
next page»
