JavaScript Syntax Errors
This section discuses some common JavaScript errors. These problems may seem trivial, but the error messages generated by these bugs may point in completely different directions. So, if you’re bewitched, bewildered, and baffled by a bug, double-check the pointers in this section.
Before we discuss specific syntax errors, let’s look at the way you can tell in a Web browser that an error has taken place.
Syntax Error Notification
If you load a page containing syntactically incorrect JavaScript into Internet Explorer, when the page loads, an error icon appears on the status bar along with a message “Done, but with errors on page,” as shown in Figure 10-2. (I’ll show you the comparable feature in Netscape later in this section.) One caveat is that if the syntax error is in code not processed as part of loading a page, for example, in an onClick event handler, then the syntax error may not display (until the event is fired).
Figure 10-2: If there are syntax errors on the page, an error icon appears on the status bar in Internet Explorer.
To show an example of the way syntax errors are displayed, I took the Tchatshke Gulch program developed in Chapter 7 and Chapter 8, and I removed a closing parenthesis from one of its functions. When the mutilated code was saved and opened in Internet Explorer, a warning icon appeared on the left of the status bar at the bottom of the browser.
Double-clicking the error icon opens a message box, which provides a line and character number for the error and describes the error (see Figure 10-3).
Figure 10-3: Double-clicking the error icon opens a message box that describes the error and provides a location.
You can use the line number provided to locate the problem by counting the number of lines in your program.
It’s the case that the interface used to tell you about syntax errors works a little different in Netscape (and Mozilla). When you open the botched Tchatshke Gulch program in Netscape, you won’t see any notification that the page contains a syntax error. You’ll need to open the JavaScript console to find an error description and line number (see Figure 10-4).
Figure 10-4: The JavaScript console provides information about syntax errors in Netscape and Mozilla.
| Note | To open the JavaScript console in Netscape (or Mozilla), select Tools |
As I’ve mentioned before, by the standards of modern development environments, this is pretty crude. Generally, good programming environments don’t let you make simple syntactic errors—they inform you of the error while the statement is open in the code editor.
Variance in Case in an Identifier
As I’ve explained, JavaScript is a weakly typed language and doesn’t require explicit variable declaration. (You can declare variables, and it’s a good idea to do so for clarity’s sake, but there’s no way to set your programs so that declaration is mandatory.)
This means that you can be happily using a variable named theKount with one or two references to thekount. You may know what should be stored in theKount, but thekount could contain anything—and certainly not something assigned by your design. The results are completely unpredictable. Be especially careful when you name variables to make them clearly distinguishable—and never, never use two variables with the same name whose only difference is the case of some of the letters.
Variable names being off because of case variance is probably the single biggest syntax-error issue in JavaScript—so watch out for it. However, you can also run into similar problems with function names. For example, if you try to call the function doSomething from an event handler:
<INPUT type=button value="Click Moi" onClick="doSomething();">
and the function is actually created with a lowercase s:
function dosomething() { } you’ll get an “Object expected” error message in Internet Explorer when the event handler is fired because the Click Moi button has been clicked. This shows up in Internet Explorer as a warning icon in the status bar, as I described earlier in this chapter. When the warning icon is double-clicked, a message box opens that describes the error and location (see Figure 10-5).
Figure 10-5: The error message in Internet Explorer provides a location for the error and a somewhat opaque description.
This error message “Object expected” is a little opaque. What does it really mean? What it’s trying to say, in its own clumsy way, is that it looked for a function named doSomething and couldn’t find it (because of the case variance).
To become an effective debugger, it helps to learn to understand the nuances of the error messages provided by the development environment.
Netscape gets the error message a little better. There’s no indication of a problem when the Click Moi button is clicked. Nothing happens. But if you open the JavaScript console, as I described earlier in this chapter, the error message “doSomething is not defined” is really quite accurate and allows you to easily spot the problem (see Figure 10-6).
Figure 10-6: The JavaScript console in Netscape provides a helpful description of the error.
HTML Issues
HTML problems can “spill over” into the surrounding JavaScript code. It’s wise to look your HTML over as well as your JavaScript if you have an otherwise intractable bug.
The cure for this problem? Be careful with your HTML. Make sure that it’s working before you add any JavaScript code.
Weird problems that don’t have any obvious solutions may indeed be HTML “spill over,” and it’s always worth having a hard look at them.
The good news is that, as you’ll discover as you progress as a programmer, in many development environments you don’t have to worry about this as an issue. If your project isn’t targeting a Web page, then likely all you have to worry about is program code. In fact, it’s worth knowing that some of the more sophisticated Web development environments—such as ASP.NET—go to great lengths to separate HTML and program code. This means that when you’re programming in these environments, you don’t have to worry about “trivial” HTML issues, such as a missing end bracket (>) on a tag.
Mismatched Parentheses
This problem of mismatched parentheses is easy to fall into and not particularly JavaScript specific. The best cure is avoidance: Lay out the parentheses and curly braces before adding content to the enclosed functions or expressions. If all else fails, start counting those left and right facing parentheses to make sure they add up.
Missing Quotes
Missing terminating quotes can present the same kind of problems as a mismatched set of parentheses in JavaScript. Because JavaScript code can involve complex string generation (often of HTML), it’s common to have nested string expressions that combine single- and double-quoted literals with variables. A missing quote could throw the whole thing off and make the JavaScript interpreter think the entire remainder of the script was a literal, creating unpredictable results.
As with parentheses, lay out the quotes before you lay in the contents. And if all else fails, count quotes to make sure they match.
Using Reserved Words As Identifiers
If you use a reserved JavaScript word such as location or open as the name of a variable or function, you’re likely to generate unpredictable results. If you have a bug and can’t find an apparent cause, double-check to make sure you haven’t used a reserved JavaScript word as an identifier.
Assigning Instead of Comparing
Assignment, indicated with one equal sign (=), and comparison, denoted with two (= =), are often confused. If you can’t find the cause of a bug, double-check to make sure your assignments are really assignments and your comparisons are really comparisons.
EAN: 2147483647
Pages: 115