Statement errors

In ABL, when the AVM is not able to properly execute a statement, the AVM most often raises the ERROR condition. From the examples you saw in Introductionto Condition Handling a FIND statement that fails to find a matching record raises the ERROR condition. If the statement failure is serious enough, the AVM may raise the STOP condition instead. For example, a RUN statement that cannot find a specified procedure file raises the STOP condition. In some cases, the statement will not raise the ERROR condition. For example, the MESSAGE statement does not raise ERROR.

In these examples, the different responses to unexpected run-time occurrences do not follow a pattern that can be summarized by a single rule. The design of each ABL statement includes decisions about how to respond to run-time conditions. The design focus is always on the appropriateness of raising a condition, given the purpose of the statement. For example:

A failed FIND statement means that record buffer data is not available for the data accessing statements that are sure to follow a FIND. So, raising the ERROR condition is appropriate.

The MESSAGE statement provides troubleshooting information or user feedback. Therefore, it is appropriate to display as much of the message as possible, even if the AVM could not resolve one or more output expressions. So, it is appropriate that the MESSAGE statement does not raise error.

OpenEdge Development: ABL Reference documents how each statement responds to run-time conditions. When using an ABL statement for the first time, a quick check of the reference entry will clarify how to handle possible errors. This is especially true for more specialized statements and system object methods. Some of these language elements may have additional error handling behavior or functionality beyond the standard functionality of the traditional error handling model.