Copyright © 2004 O'Reilly Media, Inc. All Rights Reserved.
Essential ActionScript 2.0
By Colin Moock
June 2004
ISBN: 0-596-00652-7
More info... .
Available from booksellers or direct from O'Reilly Media, www.oreilly.com.

Cover image
This content is excerpted from the above-named O'Reilly publication, with permission, by agreement with ActionScript.org.

Option 3 (adding configurable debugging messages to the BoxDimensionException class) helped us investigate a problem in our code during development, but it doesn't help the program take independent action to recover from individual Box errors. To allow the program to execute independent code branches based on the type of Box error thrown, we need custom BoxDimensionException subclasses (option 4).

Tip

If you want a program to differentiate among error conditions, implement a separate Error subclass for each one. Don't rely on the Error.message property alone to implement program branching logic. If your custom Error subclass defines a constructor that accepts an error string, you should use that string only for debugging, not for branching logic.

To allow our program to independently differentiate among the Box class's three error conditions, we create three custom exception types by creating three Error subclasses: BoxDimensionException, BoxUnderZeroException, and BoxOverflowException. In our case, the BoxDimensionException class extends Error directly. The BoxUnderZeroException and BoxOverflowException classes both extend BoxDimensionException because we want to differentiate these specific error types from a more general invalid dimension exception. Hence, the datatype hierarchy is shown in Figure 10-1.

Figure 10-1. The custom exception class hierarchy

The custom exception class hierarchy

Here's the source code for our three Box Error subclasses:

// Code in BoxDimensionException.as:
class BoxDimensionException extends Error {
public var message:String = "Illegal Box dimension specified.";
}

// Code in BoxUnderZeroException.as:
class BoxUnderZeroException extends BoxDimensionException {
public var message:String = "Box dimensions must be greater than 0.";
}

// Code in BoxOverflowException.as:
class BoxOverflowException extends BoxDimensionException {
public var message:String = "Box dimensions must be less "
+ "than Number.MAX_VALUE.";
}

Each class specifies the value of its message property directly and does not allow it to be customized on a per-use basis. Truth be told, now that we're dealing with class-based errors instead of string-based errors, the message property is completely secondary. What matters is the datatype of the exception generated by the throw statement. When catching any of the preceding Box exceptions, our program will use the exception's datatype (not the message property) to distinguish between the three kinds of exceptions.

Now that we have three exception types, let's update our setWidth( ) method to throw those types. Here's the code:

public function setWidth (w:Number):Void {
if (isNaN(w) || w == null) {
throw new BoxDimensionException( );
} else if (w <= 0) {
throw new BoxUnderZeroException( );
} else if (w > Number.MAX_VALUE) {
throw new BoxOverflowException( );
}
width = w;
}

Notice that we do not pass any error description to the various Box exception constructors. Once again, the description of each exception is set by each custom Error subclass using its message property.