User Guide

280 Handling Errors
Building a custom validator
The custom Validator class contains a single method, validateEmployeeXML(). The
validateEmployeeXML() method takes a single argument, employee, which is the XML
packet that you wish to validate. The
validateEmployeeXML() method is as follows:
public static function validateEmployeeXML(employee:XML):void
{
// checks for the integrity of items in the XML
if (employee.costCenter.length() < 1)
{
throw new FatalError(9000);
}
if (employee.costCenter.length() > 1)
{
throw new WarningError(9001);
}
if (employee.ssn.length() != 1)
{
throw new FatalError(9002);
}
}
To be validated, an employee must belong to one (and only one) cost center. If the employee
doesn’t belong to any cost centers, the method throws a FatalError, which bubbles up to the
validateData() method in the main application file. If the employee belongs to more than
one cost center, a WarningError is thrown. The final check in the XML validator is that the
user has exactly one social security number defined (the
ssn node in the XML packet). If
there is not exactly one
ssn node, a FatalError error is thrown.
You can add additional checks to the
validateEmployeeXML() method—for instance, to
ensure that the
ssn node contains a valid number, or that the employee has at least one phone
number and e-mail address defined, and that both values are valid. You can also modify the
XML so that each employee has a unique ID and specifies the ID of their manager.
Defining the ApplicationError class
The ApplicationError class serves as the base class for both the FatalError and WarningError
classes. The ApplicationError class extends the Error class, and defines its own custom
methods and properties, including defining an error ID, severity, and an XML object that
contains the custom error codes and messages. This class also defines two static constants that
are used to define the severity of each error type.