In This Chapter
Bugs! Bugs! Bugs!
Whether it's ants at a picnic or cockroaches in the closet, bugs aren't most people's favorite critters. They get in things, spoil things, and generally cause a great deal of consternation. Their appearance usually gets a standard response: insecticide, a fly swatter, or a call to the exterminator. Bugs just aren't popular—unless maybe you're a bug collector. (Any bug collectors out there, please accept my apology; I'll use the proper term: entomologist.)
Computer programs are often much like life: Programs don't always work, and when they don't, it is said (in another humorous adaptation by programmers of yore), "This program has a bug." Whether you have termites in your walls or errors in your code, a bug is a bug, and a bug isn't good.
The End Result
The more insidious bugs, perhaps not unlike termites deep in the foundation, are those that are not illegal statements but are based on incorrect logic. Your program executes because the statements are "legal," but the results are incorrect because your programming logic was flawed at some point. These can be extremely difficult to exterminate. We'll discuss such nasties second.
BZZT! The ERROR
By far, the most common source of bugs is the typographical error. In a word: that darned misspelling. Unlike humans, who can still get the general idea of what you're trying to say (whether you remember to put the "i" before the "e" or not), computers aren't so flexible. If it isn't spelled exactly right, the computer doesn't have a clue what you mean. The problem with "typos," as they're called, is that (as you saw in the previous section) the browser isn't smart enough to say, "Ahh, you didn't spell it right." If it were, the browser would know what the right value was...right?
Instead, a typo can cause one of several things to happen:
And the list goes on...and on...and on. In a nutshell, spelling something wrong is a lot like trying to order food in a French bistro when you don't speak French: Depending on what word you get wrong, you could end up with anything from a scoop of sorbet to a boiled shoe. Check your spelling!
A Capital Idea
It is not uncommon to find multiple closing parentheses or brackets at the end of a series of statements; each one pairs up with an opening mate that appears earlier. It might look strange, but an eye for an eye and a bracket for a bracket, as they say (don't they?). Well, it’s something to watch for.
????? Is Not Defined
You've already met this guy. He's trying to tell you that either you misspelled something or you have forgotten to include the function body (the guts of the function) in the script. It might also mean that the function requires an uppercase letter or two, so you might want to check the function against what you find here in the book.
????? Is Not a Function
You tried to call an object's function (for example, document.write()), but the function doesn't exist. Check the spelling and capitalization.
????? Is Not a Numeric Literal
You attempted to perform some sort of math operation on a string. For example, if you wanted to take the numeric value 2 and display “2nd” on the screen, something like this
document.write(2 + "nd");
To get around this, you need to "convert" the expression to a string before you start evaluating it. You can easily do this by adding a "null" or "empty" string in front of the number like this:
document.write("" + 2 + "nd");
The Dreaded Crash
Sometimes things get really hairy, and you're presented with the infamous "illegal operation" dialog box.
This message means that something’s seriously wrong!
After you see this message, Netscape or Internet Explorer itself shuts down. First rule: don't panic. Chances are you've made some simple mistake, and although the browser should have a better way of handling it, instead it charges forward blindly until it gets hopelessly stuck.
A common way to cause this error (if you really like creating bugs instead of fixing them) is to try to treat a numeric value like a string and manipulate it. For example, this code
will definitely cause a crash. However, if you convert the number to a string first, like this
then everything's fine.
Design Errors (or “Why Did My House Just Collapse?”)
Finding the Holes Where the Rain Gets In
To locate the region of code where the flaw most likely is, you have to consider the program itself. Presumably, you have several functions in such a program, each of which performs some calculation. Therefore, any of those would make good suspects at this point; after all, a wrong final tally is probably caused by an erroneous calculation.
Look at the sections of code you might suspect. Read them over carefully and follow the logic in your mind. If no flaw is immediately apparent, dip into the programmer's toolbox for handy debugging tool number one: the inside scooper.
When the program executes again, the values for those variables are displayed, giving you a clue as to whether they are at least what you were expecting them to be. If they aren't, you must begin your investigation again, but at least you've narrowed it down. (Do remember, though, to remove these lines of code once the program is working because they're not intended to be part of the final program.)
In addition to variable values, another common test is for program flow. Did the execution even reach your function? Perhaps your function was never even executed because of some other design flaw in your logic. You can easily test for this just as you did before: somewhere within the questionable function, stick a line that you're sure will generate some action if the function is, in fact, being executed. You could insert the line window.alert ("Hi function bob was just called"), for instance.
Sigh and Rebuild
Using some combination of the previous example—perhaps many times, if necessary—you will eventually track down the region of code that is logically flawed. From there, you must identify the flaw and rebuild to correct it. Once you're certain you have the right portion of code, the only sure way to identify the flaw, is to step through it mentally, bit by bit. In a Zen-like way, imagine that you are the computer, and attempt to interpret the code exactly as the computer would. You might even grab a pencil and paper and write down the values of variables as you progress through your mental exercise. This can be very tough work. Sometimes the logic flaw will pop out at you quickly. In a most difficult case, however, you might be completely stumped. This is the "art" of programming.
The Mighty Debugger
The Least You Need to Know
If your code is free from grammatical errors, it might be suffering from design flaw. You need to examine the logic of your code. For that purpose, you might try these suggestions:
For comments or technical support for our books and software, select Talk to Us. © 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon & Schuster Company.
To order books, call us at 800-716-0044 or 317-228-4366.
© 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon & Schuster Company.