Progress.Lang.AppError is the ultimate super class of all application errors. An application error is simply any collection of data you need to provide necessary information about a condition. Representing a user-defined error as an error object allows your application to throw and catch or return the error in the ABL structured error handling model.
The following figure represents the hierarchy of ABL classes that provide Progress.Lang.AppError with all its features:
Figure 1. Hierarchy of ABL error classes
Progress.Lang.ProError is the ultimate super class of all error objects in ABL. From Progress.Lang.Object it inherits the basic features of an ABL class. It also implements the Progress.Lang.Error interface, which provides the basic properties and methods for handling errors. Progress.Lang.AppError adds the ability to add your own error messages, and it also includes a ReturnValue property. You can also create your own hierarchy of more complex AppError types by creating subclasses of AppError.
In traditional error handling, a called context can communicate with a calling context by using the RETURN ERROR statement and optionally providing a descriptive CHARCTER string. This returned string is analogous to an application error since it amounts to a user-defined error message or error data. You use the RETURN-VALUE function in the caller to access the string. When the AVM encounters the RETURN ERROR statement, it throws a Progress.Lang.AppError error object and places any specified string in the object's ReturnValue property. The error object itself is only seen if if it is caught by a CATCH block.
Progress.Lang.AppError class provides the ability to define error objects at run time. In ABL, user-defined error types are called application errors. The Progress.Lang.AppError class lets you define application errors that are handled like ABL system errors. In this paradigm, an error object consists of one or more descriptive CHARACTER messages, each with an associated INTEGER message number.
