Classes support features for error handling that are not available in previous OpenEdge releases. These features help to solve many general error handling challenges by supporting an error handling model that uses class-based objects to store and propagate error information throughout an ABL application.
In OpenEdge releases prior to 10.1C, the entire ABL error handling model primarily supports the management of OpenEdge system errors, with limited support for recording and raising application errors using RETURN ERROR in various ABL contexts. With this model, both system and application errors can raise a single ERROR condition. You can then trap this ERROR condition at different levels of an application and with varying degrees of control. Once trapped, you can further examine a system error using attributes and methods of the ERROR-STATUS system handle, or you can examine an optional setting of the RETURN-VALUE function for more information on an application error. In addition, if you do not handle an ERROR condition, the AVM displays an error message and standard ABL UNDO handling occurs, which can roll back transactions.
However, this model provides little or no context information about a given error and does so in an inconsistent manner. Depending on the context, you might have to use different mechanisms, other than raising the ERROR condition, for returning and handling errors that have no automatic effect on transactions. For example, built-in handle methods do not raise ERROR when called. So, to check for an error on a built-in handle method call, you must always check the ERROR-STATUS handle for the presence of a message after the call. You then might raise ERROR based on the message contents to affect a transaction.
This ABL traditional error handling model is efficient and works in many application situations. In the present OpenEdge release, you can continue to use the traditional error handling model as in any previous release. However, ABL also supports an additional model for handling errors—the structured error handling model. This model provides a consistent mechanism for handling both application and system errors using standardized class-based error objects. It allows you to customize application error objects with application-specific data, and the model is fully compatible with the ERROR condition mechanisms of traditional error handling. You can thus use structured error handling alone or together with traditional error handling in both procedure-based and class-based applications.
The following sections provide a brief introduction to ABL structured error handling and its relationship with traditional error handling, and include specific information on raising and handling errors in a class-based application environment using either error handling model:
