As a general feature of computer languages, structured error handling is an error management model where an error is encapsulated by a class instance whose type depends on the type of error. Once created, this error object can be passed (thrown ) to various parts of a computer program, where it might be examined (caught ), modified, and optionally thrown to other parts of the program, all using the same standard mechanisms.
ABL supports structured error handling using the following basic elements:
Error classes — A set of built-in and user-defined classes that inherit directly or indirectly from the Progress.Lang.ProError class. These classes are used to instantiate error objects that encapsulate various types of system and application errors. When any system error occurs, the AVM instantiates and throws an instance of the built-in class Progress.Lang.SysError (subclass of Progress.Lang.ProError). You can also instantiate and throw an application error object, a Progress.Lang.AppError (subclass of Progress.Lang.ProError) using a RETURN ERROR. You can extend Progress.Lang.AppError with additional members to define new classes that encapsulate different types of application errors. You can then throw error objects instantiated from these classes like all the built-in error classes.
Error throwing mechanism — An UNDO, THROW option of several ABL elements that raises ERROR and throws a specified error object to the associated block (the block where a particular ERROR condition is raised), which can handle the ERROR condition in a variety of well-defined ways. Using this option, you can throw a current system or application error object, or throw a new application error object that you create. Note that UNDO, THROW, by raising ERROR, also initiates the same UNDO handling as the traditional error handling model, when raising ERROR with a RETURNERROR.
Error catching mechanism — A CATCH statement that defines a special block that can catch and process an error object of any specified type that is thrown to the associated block. It is this CATCH block, which is available for use in all UNDO blocks, where you can decide whether to access the caught error object, throw the same or a new error object, or do nothing further with the error. Note that the CATCH statement is analogous to using the NO-ERROR option on a statement or the ON ERROR phrase (or default ON ERROR setting) on a block, both of which provide options for responding to ERROR conditions using traditional error handling. However, unlike the ON ERROR phrase, the CATCH block available with the CATCH statement is available for use in all UNDO blocks, including procedure, user-defined, function, and method blocks, and it allows, in one mechanism, far greater application control over many more kinds of error conditions than is possible with the NO-ERROR option and ON ERROR phrase.
Thus, structured error handling in ABL provides a more flexible and robust error handling model than traditional error handling, and it is often easier to use. You can, in fact, use both structured and traditional error handling in the same application. The two error models are fully compatible, even though each model handles errors differently. That is, using UNDO, THROW to throw an error object always raises the ERROR condition, and using RETURN ERROR to raise ERROR always throws an error object of one type or another; likewise, a system error both raises ERROR and throws a Progress.Lang.SysError object. Similarly, an error raised by any of these mechanisms can be handled by the error handling mechanisms of either model, including a CATCH block, the NO-ERROR option, or the ON ERROR phrase (or its default) setting.
In order to fully integrate the two models, ABL recognizes an order of precedence in how the mechanisms of traditional and structured error handling work together. Thus, when ERROR is raised in any way, ABL applies one of the possible mechanisms for handling that error in the associated block, depending on the mechanisms specified and available in a given context, and it chooses the mechanism according to the following order of precedence:
1. An appropriate NO-ERROR option
2. An appropriate CATCH statement
3. An explicit setting of the ON ERROR phrase for the block
4. The default setting of the ON ERROR phrase for the block, which can be changed on a routine-level block using the ROUTINE-LEVEL ON ERROR UNDO, THROW statement
For more information on error handling, including how to use both ABL structured and traditional error handling, see OpenEdge Development: Error Handling. The remainder of this section describes aspects of working with both error handling models in classes.
Error classes — A set of built-in and user-defined classes that inherit directly or indirectly from the Progress.Lang.ProError class. These classes are used to instantiate error objects that encapsulate various types of system and application errors. When any system error occurs, the AVM instantiates and throws an instance of the built-in class Progress.Lang.SysError (subclass of Progress.Lang.ProError). You can also instantiate and throw an application error object, a Progress.Lang.AppError (subclass of Progress.Lang.ProError) using a RETURN ERROR. You can extend Progress.Lang.AppError with additional members to define new classes that encapsulate different types of application errors. You can then throw error objects instantiated from these classes like all the built-in error classes.