Exception Handling in JavaScript: Addressing Browser Incompatibilities

The simple script that you just saw to create XMLHTTP objects can be rewritten by using “try-catch” blocks for handling object instantiation. Even when this method may require a few additional lines of code, the overall script’s structure is more robust. Bearing in mind this concept, here’s what an exception-based script looks like:

// XMLHttpRequest object detection using exceptions
try{
    // browser is Firefox, Netscape, etc.
    // use XMLHttpRequest object
    var objXML=new XMLHttpRequest();
}
// catch thrown error
catch(e){
    try{
        // browser is Internet Explorer
        // use ActiveX Control
        var objXML=new ActiveXObject("Microsoft.XMLHTTP");
    }
    // catch thrown error
    catch (e){
        alert('Ajax is not supported on your browser!');
    }
}
// open socket connection
objXML.open('GET','samplefile.htm',true);
// send request header
objXML.setRequestHeader('Content-Type','text/html; charset=iso-
8859-1');
// send data
objXML.send('var1=1&var2=2');

Consider the above listed script, which now uses exceptions for instantiating the correct XMLHTTP object, according to the browser where the code is executed. In simple terms, what I’ve done is use a “try” block to wrap up the first line that attempts to create an XMLHTTP object, as depicted in the line below:

try{
    var objXML=new XMLHttpRequest();
}

As you can see, if the pertinent object can be successfully created, it means that the browser natively supports it (Firefox, Nestcape and so forth). Otherwise, an exception will be thrown by the expression, being caught by the next “catch” block, in the following way:

// catch thrown error
catch(e){
    try{
        // browser is Internet Explorer
        // use ActiveX Control
        var objXML=new ActiveXObject("Microsoft.XMLHTTP");
    }
    // catch thrown error
    catch (e){
        alert('Ajax is not supported on your browser!');
    }
}

Similarly, the above “catch” block traps the raised error and tries to instantiate the object by using an ActiveX control (in the case of Internet Explorer). Due to the fact that the code responsible for instantiating the object is placed within another “try” block, any potential error can be easily handled through an additional “catch” block. Of course, if program control is moved to this last statement, it means that the browser doesn’t support XMLHTTP objects, therefore a warning alert is displayed.

Even when the sample script you just saw requires additional code for checking object support, it looks more elegant and professional. It’s a matter of personal preference how you will implement cross-browser object creation in your programs.

However, as you’ll probably agree, built-in exceptions provide a powerful mechanism for trapping most errors, including those ones that occurred when trying to create objects, so the above method should be appropriately considered.

Having explained how exceptions can be used for addressing browser differences, it’s time to see another example. Therefore, the next case to be reviewed explains how to manipulate proprietary event handlers.