Try OpenEdge Now
skip to main content
Error Handling
Using Structured Error Handling : Comparison to traditional error handling
 

Comparison to traditional error handling

The remainder of this manual will help you build your structured error handling skills with a thorough explanation of each component of the model and the associated programming tasks. It is useful to review traditional error handling, as it forms the roots of structured error handling.
Your knowledge of traditional error handling is an essential beginning for understanding structured error handling in ABL. TraditionalError Handling began with a list of tasks you needed to understand to successfully use traditional error handling. The following table presents a related similar list of traditional error handling concepts and summarizes how the particular concept changes in structured error handling.
Table 8. Traditional versus structured error handling
Traditional error handling concept
Comparison to structured error handling
Know what raises ERROR
Whether a statement raises ERROR is not normally dependent on which error handling model is in effect in a block. However, the presence of a CATCH block in any block allows all errors to be handled more consistently, since it can handle errors that cannot be handled by the NO-ERROR option or ON ERROR phrase.In particular, statements that do not raise ERROR in traditional error handling, like the MESSAGE statement, now raise ERROR when CATCH is present.In traditional error handling, methods on built-in system handles treat errors as warnings. Therefore, built-in methods do not raise ERROR. If a CATCH block is present in the block containing a failed built-in method, the AVM will now raise ERROR.Note that an error handled by a CATCH block makes the block subject to UNDO. The NO-ERROR option is still useful to suppress an error and avoid UNDO of the block.
Understanding OpenEdge messages
System error messages are the same. Because they are wrapped by error objects, you access the messages by properties and methods on the error object, as opposed to attributes and methods on the ERROR-STATUS system handle.
Know how a particular block handles an error
Default error handling is the same in both models.
Know how to use block statement options to alter default error handling
For explicit error handling, the ON ERROR phrase and UNDO statement all support the THROW option. THROW suppresses display of default error messages, exits the block, and passes the error raised in the block to the immediate outer block.Two statements enable you to change default error handling behavior for whole files: ROUTINE-LEVEL ON ERROR UNDO, THROW and BLOCK-LEVEL ON ERROR UNDO, THROW. Similarly, a compile-time startup parameter, -undothrow, lets you implement the same behaviors for an entire application.
Know how to suppress unwanted errors
When a CATCH block for a particular error type is in effect, the AVM will not display an error message. The error message is instead placed within the error object created by the AVM. If there is no CATCH block for the particular error type, then the AVM will display an error to the standard output.The NO-ERROR option is an important part of structured error handling. It is the only option that can prevent a statement within a block from raising ERROR where it otherwise would. Even when a CATCH block is present that would handle the error a statement raises, if the NO-ERROR option is used on the statement, the CATCH block ignores it.
Know how to test for errors after a NO-ERROR option and branch to your custom error handling logic
If you use the NO-ERROR option to prevent a statement from being handled by a CATCH block, then the ERROR-STATUS system handle continues to be the tool you use to determine if an error occurred on the statement and what the error or errors were.You can think of the NO-ERROR and ERROR-STATUS combination as a miniature CATCH block on a single statement.
Know how to raise ERROR and specify an application custom error data
The RETURN ERROR statement and RETURN option of the ON ERROR phrase and UNDO statement are still your ways for raising application errors. You can now raise (THROW) your own error object.The THROW option also provides the way to raise ERROR in a user-defined function, as explained in detail in THROWwith user-defined functions.
Know how to undo transactions
The UNDO statement is still your method for undoing transactions. Structured error handling adds the THROW option to this statement.
Understanding STOP and QUIT condition processing
Structured error handling does not handle STOP and QUIT conditions.