System Response after a Class-Based Exception

A class-based exception can occur in a statement block for one of the following reasons:

• The exception is triggered explicitly with the RAISE EXCEPTION statement.

• The exception is triggered implicitly by the ABAP runtime environment.

In both cases, the occurrence of a class-based exception interrupts the sequential processing of the current processing block, and the system responds as follows:

• If the exception occurs during execution of a TRY block of a TRY control structure, an appropriate CATCH block is searched as a handler. Execution of each TRY block opens a context, also called a protected area, into which the execution of other TRY blocks can be embedded. Usually, it is embedded by means of the call of procedures, less frequently by means of nesting TRY blocks in the source text. Starting at the position where the execption occurs, the system scans the TRY control structures of the participating TRY blocks from the inside to the outside for the first CATCH block, in which the exception class or one of its superclasses appears. If it finds a CATCH block, it executes it and continues processing after its TRY control structure.

• If no handlers are found in any of the participating TRY control structures of a protected area, or if the exception does not occur during processing of a TRY block of a TRY control structure, a runtime error occurs at the point where the exception occurred. The short dump of the runtime error contains the name of the exception class and the exception text.

Note the following special features:

• If the use leaves the procedure context during the handler search, the procedure's interface will be checked. Only exceptions declared there can be propagated from the procedure. Exceptions of the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be declared explicitly, while exceptions of category CX_NO_CHECK are always declared implicitly. If the exception is not declared in the interface, the exception of the predefined class CX_SY_NO_HANDLER is triggered at the call position of the procedure, in whose attribute PREVIOUS a reference to the original exception is stored. This is done at the call position of the procedure,

• If a handler is found, the CLEANUP blocks of all TRY control structures that have thus far been scanned unsuccessfully are executed from the inside to the outside. This is not the case with TRY control structures for which the exception occurs in a CATCH block (a CATCH block does not belong to the protected area). Exceptions that occur in a CLEANUP block must be handled in the block, and cannot leave it.