Professional JavaScript | 9 | WebReference

Professional JavaScript | 9

1234
[previous] [next]

Professional JavaScript

Exception Syntax vs 'if'

If you've never used exceptions before, you're likely to be very skeptical about the syntax arrangements required to get them working by now.

Common objections to the above example are:

For simple cases, it must be admitted that the argument for exceptions is weak; the exception-style code can definitely be bigger. More generally, the argument for using exception syntax goes like this:

It must be admitted that you don't always need exceptions. Simple scripts that just perform sequences of guaranteed operations have no need of exceptions at all, really.

Here is an example that shows exception syntax working for the scriptwriter rather than against:


// piece of code that could fail 20 different ways
try {
  // might cause 1 of 5 exceptions
   dodgy_task_1();
  // might cause 1 of 4 exceptions
  dodgy_task_2();
  // might cause 1 of 7 exceptions
  dodgy_task_3();
 
  // might cause 1 of 4 exceptions
  dodgy_task_4();
}
catch (everything)
{
   // scream blue murder
}

Because a throw statement immediately aborts the try block, each dodgy function can come straight after the other, confident that if something goes wrong, the latter ones will never be executed. We've saved a heap of if tests by using the try block in this case. Note that functions needn't have a return value (other than the default of void) in order to make use of exceptions.

Finally, you needn't restrict yourself to throwing primitive types. Here's some paired code that illustrates:


// throws an object
throw { err_string:"You're doomed", err_number: 23 };

This statement creates a two-property object and returns that as the thrown item. // catches only error number 23 catch ( e if ( e.err_number == 23) ) { … }

This statement expects the exception to be an object with an err_number property, which clearly will be the case if the previous throw statement is responsible for the exception.

Exceptions vs Events vs Errors

If you've messed around with JavaScript in browsers a little before reading this book, then you might be aware that there exist triggers or events that can make JavaScript script fragments run, especially if a given web page contains forms. Are these exceptions or not?

These kinds of events are not generally considered exceptions. Events, generally occurring as a form of input from a user or a network, are expected, planned for, and normal occurrences. They are usually handled the same as normal data. Exceptions are not considered normal, and are usually used for error conditions – something went wrong that the script has been able to anticipate (with try/catch blocks), but can't really handle normally.

Sometimes it's easy to relate events and exceptions together. This is because the way a script gets ready for events is typically a little different to the way it receives plainer kinds of user input. This oddity of handling events can seem similar to the oddity of handling exceptions. Nevertheless, they are separate and different. Chapter 7 on Forms and Data gives a flavor of what ordinary events are like, and if you look there, you'll see there's not a mention of JavaScript exception syntax anywhere.

Exceptions Make Sense for Host Objects

A further reason for exception handling support in JavaScript is to be found in host objects. Without host objects JavaScript is nearly useless. What if those host objects generate exceptions as part of their attribute/method/exception interface? There must be a mechanism in place in JavaScript to support this kind of communication. This is especially the case if JavaScript is to work closely with Java, which has support for exceptions deeply ingrained in its language.

Exceptions Make Sense for Interpreter Errors

Some things that go wrong with JavaScript scripts can be pretty bad. If the scriptwriter has made a typographical error in some obscure part of a large script, it might never be detected until that script is installed in some critical place. That is the risk you take with an interpreted language.

If the interpreter comes to read the script and finds a typographical error, wouldn't it be nice if there were something that could be done about it rather than the whole script just stopping dead? This is a future direction for the ECMAScript standard – scripting errors might be reported as exceptions and handled by the system that starts the JavaScript interpreter in the first place.

1234
[previous] [next]
and
Created: February 12, 2001
Revised: February 16, 2001

URL: http://webreference.com/programming/javascript/professional/chap3/