4.7 Handling Script Errors Gracefully

NN 6, IE 5

4.7.1 Problem

You want to process all script errors out of view of users, and thus prevent the browser from reporting errors to the user.

4.7.2 Solution

The quick-and-dirty, backward-compatible way to prevent runtime script errors from showing themselves to users is to include the following statements in a script within the head portion of a page:

function doNothing( ) {return true;}
window.onerror = doNothing;

This won't stop compile-time script errors (e.g., syntax errors that the interpreter discovers as the page loads). It also won't reveal to you, the programmer, where errors lurk in your code. Add this only if you need to deploy a page before you have fully debugged the code; remove it to test your code.

In IE 5 or later and Netscape 6 or later, you can use more formal error (exception) handling. To prevent earlier browsers from tripping up on the specialized syntax used for this type of processing, embed these statements in <script> tags that specify JavaScript 1.5 as the language attribute (language="JavaScript1.5").

Wrap statements that might cause (throw) an exception in a try/catch construction. The statement to execute goes into the try section, while the catch section processes any exception that occurs:

<script type="text/javascript" language="JavaScript1.5">
function myFunc( ) {
    try {
        // statement(s) that could throw an error if various conditions aren't right
    }
    catch(e) {
        // statements that handle the exception (error object passed to e variable)
    }
}
</script>

Even if you do nothing in the catch section, the exception in the try section is not fatal. Subsequent processing in the function, if any, goes on, provided it is not dependent upon values created in the try section. Or, you can bypass further processing in the function and gracefully exit by executing a return statement inside the catch section.

4.7.3 Discussion

Each thrown exception generates an instance of the JavaScript Error object. A reference to this object reaches the catch portion of a try/catch construction as a parameter to the catch clause. Script statements inside the catch clause may examine properties of the object to learn more about the nature of the error. Only a couple of properties are officially sanctioned in the ECMAScript standard so far, but some browsers implement additional properties that contain the same kind of information you see in script error messages. Table 4-2 lists informative Error object properties and their browser support.

Table 4-2. Error properties

Property	IE/Windows	IE/Mac	NN	Description
description	5	5	n/a	Plain-language description of error
fileName	n/a	n/a	6	URI of the file containing the script throwing the error
lineNumber	n/a	n/a	6	Source code line number of error
message	5.5	n/a	6	Plain-language description of error (ECMA)
name	5.5	n/a	6	Error type (ECMA)
number	5	5	n/a	Microsoft proprietary error number

Error messages are never intended to be seen by users. Use the description or message property of an error object in your own exception handling to decide how to process the exception. Unfortunately, the precise message from the various browsers is not always identical for a given error. For example, if you try to reference an undefined object, IE reports the description string as:

'myObject' is undefined

Netscape 6 or later, on the other hand, reports:

myObject is not defined

This makes cross-browser exception handling a bit difficult. In this case, you could try to fudge it by performing string lookups (regular expression matches) for the object reference and the fragment "defined" as in the following:

try {
    window.onmouseover = trackPosition;
}
catch(e) {
    var msg = (e.message) ? e.message : e.description;
    if (/trackPosition/.exec(msg) && /defined/.exec(msg)) {
        // trackPosition function does not exist within page scope
    }
}

You can also intentionally throw an exception as a way to build exception handling into your own processing. The following function is a variation of a form validation function that tests for the entry of only a number in a text box. The try clause tests for an incorrect value. If found, the clause creates its own instance of an Error object and uses the throw method to trigger an exception. Of course, the thrown exception is immediately caught by the following catch clause, which displays the alert message and refocuses the text box in question:

function processNumber(inputField) {
    try {
        var inpVal = parseInt(inputField.value, 10);
        if (isNaN(inpVal)) {
            var msg = "Please enter a number only.";
            var err = new Error(msg);
            if (!err.message) {
                err.message = msg;
            }
            throw err;
        }
        // it's safe to process number here
    }
    catch (e) {
        alert(e.message);
        inputField.focus( );
        inputField.select( );
    }
}

This kind of function is invoked by both an onchange event handler for the text field and a batch validation routine, as described in Chapter 8.