Internet Explorer 5.0 Review, Part IV: Exception Handling, JavaScript-checked Errors - www.docjavascript.com | WebReference

Internet Explorer 5.0 Review, Part IV: Exception Handling, JavaScript-checked Errors - www.docjavascript.com


Internet Explorer 5.0 Review, Part IV: Exception Handling (2)

Handling JavaScript-thrown Exceptions

In any programming language, your code will throw a run-time exception when trying to execute an illegal command. One of the most trivial illegal operations you may attempt is a division by zero. Your operating system will definitely complain when trying to divide a number by zero. This is not a good example, as JavaScript does execute the operation and assigns infinity to the resulting variable. Other illegal operations are common to most programming languages, including JavaScript. Accessing a null pointer or a null object is one example. Accessing an array element that is out of the array's legal range is another.

More often than not, you want to avoid system errors. System messages are usually cryptic and do not make sense for the average user. In fact, system messages are bad for your reputation as a programmer, as they are clear and tangible evidence of your bugs. Naturally, you'll want to avoid these messages by checking for them in your code, before they hit the operating system. Checking for exceptions in your code will surely make it more cumbersome. Mingling error-checking with the normal flow of your code is inevitable when the language does not support exception handling. The following skeleton code checks for two errors: accessing a null object and out of range array element:

var newObject = createObject(dataPiece1, dataPiece2, dataPiece3);
if (newObject == null) {
  // do something here when the object was not created
  ...
}
else {
  // getElementIndex return an index or -1 for an error
  var index = newObject.getElementIndex();
  if (index == -1) {
    // handle the error case
    ...
  }
  else {
  {
   // finally, you can do something with index
   ...
  }

The crux of the exception handling support in JavaScript (as well as in other languages, as explained later in this column) is the try...catch statement. The try keyword precedes a block of normal processing code that may throw an exception. The catch keyword precedes a block of exception handling code. Once an exception is thrown from a try block, control over the program flow switches to the first catch block following it. Once thrown by JavaScript (as opposed to the programmer), there is no mechanism to figure out the error type. Here is the try...catch block you may use to mimic the flow above:

try {
  var newObject = createObject(dataPiece1, dataPiece2, dataPiece3);
  var index = newObject.getElementIndex();
    // do something with index
}
catch {
  alert("System Error; Call your sw vendor");
}

Here is another example that you can actually run on your computer:

<HTML>
<HEAD>
<TITLE> example 1 </TITLE>
</HEAD>
<BODY>
<IMG SRC="doc.gif">
<SCRIPT LANGUAGE="JavaScript1.2">
<!--
try {
  for (image=0; image < document.images.length + 2; image++) {
    alert(document.images[image].border);
  }
}
catch (kuku) {
   alert("We have experienced a JavaScript error");
}
// -->
</SCRIPT>
</BODY>
</HTML>

The exception enforced in this example is accessing an array element that is outside the array boundaries. The highest index used is length+1 (2) while we have only a length (1) number of images on the page (doc.gif). Notice the variable kuku we pass to the catch block. JavaScript allows passing of any variable types, as explained in the following pages. Although we don't make any use of this variable, you must specify one.

https://www.internet.com

Produced by Yehuda Shiran and Tomer Shiran

Created: April 26, 1999
Revised: April 26, 1999

URL: https://www.webreference.com/js/column38/jserror.html