Debugging JavaScript: Understanding JavaScript Error Messages | WebReference

Debugging JavaScript: Understanding JavaScript Error Messages

By Rob Gravelle


One of the most pervasive criticisms about JavaScript is that it's painfully difficult to debug. Some shops (mine included) have gone to great lengths to minimize JavaScript code by transferring functionality to the server and using Ajax to feed values and properties back to the page. That's a reasonable solution for large applications, but it's a lot of overhead for smaller websites. The good news is that you don't have to be intimidated or turned off by JavaScript. There are plenty of ways to ferret out even the most obscure bugs, from writing your own tracing functions to developing in full-featured IDEs. In this article, we will be taking a look at the types of errors that you are likely to encounter in JavaScript development and how to minimize the chance of them cropping up in your code.

Three Types of Errors to Look For

JavaScript is susceptible to the same kind of errors as the vast majority of programming languages. These include:

  • Loading Errors:
    These are the equivalent of compile errors in languages such as C++ and Java. Since JavaScript code is an interpreted language, even the most prominent errors won't be caught until the script is loaded in a browser. This type of error, which has the grave effect of halting script execution immediately, can usually be spotted by an error message that refers to some kind of incorrect syntax, such as a missing brace or function parentheses.

  • Runtime Errors:
    The second type of error occurs when the JavaScript interpreter comes across some code that it can't understand. Again, syntax errors, such as misspelled variable names, may be the culprit. Illegal assignments, such as to the this pointer, will also cause a runtime error.

  • Logic Errors:
    Errors in processing logic, which can result from misunderstanding the requirements to not drinking enough coffee, are what lead to what developers affectionately refer to as "bugs". A bug can manifest itself as a JavaScript error in any number of ways. Suppose that you wrote a process that expects JSON-formatted data to be returned from the server. Unbeknownst to you, the owner of that application transfers data in XML format. You had better have some thorough error handling in place, or be ready for some strange behavior!

Anatomy of a JavaScript Error Message

Figure 1

The above image shows a typical JavaScript error in Internet Explorer. There are five pieces of information conveyed: the line number, character, error message, error code (number), and URL address of the page.

The line number, in particular, turns out to be a lot less helpful than you might expect. Browsers differ in their determination of the line number and thus do not reliably report the correct line number that an error occurred at in relation to the source code. Internet Explorer, for instance, reports the line number in relation to the browser's own internal rendering of the document source, which may or may not match the source file! Firefox reports the location of the error more reliably, reporting the script file that an error occurred in where applicable. Firefox will not however provide you with details about the element that caused the error, known as the "caller". This information, which can be useful in quickly tracing the cause of an error, is currently only provided by Internet Explorer.

So what can you do with the line number? While not an exact science, it can help you pinpoint the general place in the script where things went awry. One easy trick is to copy the document source and paste it into a text editor that provides line numbering, such as Textpad. Alternatively, you can set the default HTML Editor on the Programs tab of the Internet Options dialog:

Figure 2

It can then be accessed from the File menu:

Figure 3

Common Browser Messages and What They Mean

To say that JavaScript error messages can be difficult to decipher would be generous! Here are some classics that you're bound to recognize:

"Object expected" ( or "[something] is undefined")

This two word message wins the award for most succinct. In any other language, the phrase "object expected" would mean that a function was expecting an object when a native type was supplied. Not so in JavaScript! Since it is a loosely-typed language, it doesn't really make a distinction between objects and native variables. Most likely, it means you are missing an external JavaScript file, or have supplied a wrong path to the script. Specifically, it's saying that a function being called or a variable being referred to is not available.

"Unterminated string constant"

The most common cause of this error is mismatched quotes. JavaScript's use of both single and double quotes as string delimiters can be a double-edged sword. You have to be very careful to match them up and escape quotes that are included in text. In the following example, the apostrophe in the word "can't" should have been escaped:

To escape a character, precede it with a backslash(\).

"Expected ')' or missing ) after argument list"

This error is usually referring to an array or function arguments. It could mean that you left out a comma between array elements or inserted an unescaped apostrophe in an array element enclosed in single quotes. Here are three examples of incorrect array syntax: