Generally speaking, a condition differs from other run-time events in that it is unexpected and requires a response to restore application flow. In ABL, a condition always invokes a default response, which is called default error handling.

Note: An ERROR is the most common type of condition, which is why condition handling is usually referred to as error handling in ABL documentation.

Default error handling protects your database while also providing branching options to restore application flow. You design your ABL application to accept default error handling, or to replace it with custom error handling.

ABL recognizes these four conditions, all of which are keywords:

  • ERROR

    An ERROR occurs when:

    • The AVM fails to execute an ABL statement. For example, if a FIND statement fails to find a matching record, then the statement fails. These failures are detected at run time by the AVM which then raises the ERROR condition. These errors are known as system errors. A system error is associated with a number and a descriptive message.
    • Your application executes the RETURN ERROR statement or throws an instance of Progress.Lang.AppError. An error raised in this way is called an application error.
    • An application uses the APPLY "ERROR" statement. This is considered outdated functionality.

    In all cases, when an error condition is raised in a block with error handling, it is not raised again beyond that block unless some ABL code explicitly instructs the AVM to do so. In other words, the default is that errors are local and are not propagated beyond the current block context.

  • STOP

    The STOP condition represents a more serious condition and occurs when:

    • The AVM encounters a system error that is deemed more serious or unrecoverable. For example, if the AVM detects a lost database connection, the AVM raises the STOP condition.
    • Your application executes a STOP statement.
    • An application user presses the key mapped to the STOP key code when input is enabled. By default, this is CTRL+C on Unix/Linux or CTRL+Break in Windows.
    • The specified time has expired when using a STOP-AFTER phrase on a block.
    • A record lock conflict occurs and the user either cancels out of the ensuing record lock conflict dialog, or there is no user response (including in batch mode) within the time specified by the -lkwtmo startup parameter.

    In all cases, when a STOP condition is raised in a block, it is then raised again in all blocks up the call stack unless it is handled by explicit ABL code. In other words, the default is that STOP conditions propagate up the call stack indefinitely until the application ends. In addition, there are a few cases where the AVM ignores explicit attempts to handle a STOP condition, until either the current transaction is over or until the AVM has returned up past the code layer that accesses the database, depending on the condition.

  • QUIT

    The QUIT condition only occurs when your application executes a QUIT statement. It causes any open transaction to be committed and the AVM session to terminate. As the AVM unwinds the stack, the QUIT condition is in effect.

  • ENDKEY

    The ENDKEY condition occurs when:

    • An application user presses a key that is mapped to the ENDKEY key code (typically ESC) when input is enabled. This has different default behavior depending on the context. For example, it may back out editing entered by a user in an ABL widget, or it may close the current window if no editing is taking place. This style of user interface was designed for character mode applications and is no longer relevant to most modern applications.
    • The application reaches the end of an input stream.