ABAP Keyword Documentation → ABAP - Reference → Program Flow → Exception Handling → Class-Based Exceptions
System Response after a Class-Based Exception
A class-based exception can be raised in a statement block for one of the following reasons:
- The exception is raised explicitly by the
- The exception is raised 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 is raised when a
TRYblock of a
TRYcontrol structure is executed, an appropriate
CATCHblock is searched as a handler. Execution of each
TRYblock opens a context, also called a protected area, into which the execution of other
TRYblocks can be embedded. Usually, it is embedded by means of the call of procedures, less frequently by means of nesting
TRYblocks in the source text. Starting at the position where the execption is raised, the system scans the
TRYcontrol structures of the participating
TRYblocks from the inside to the outside for the first
CATCHblock, in which the exception class or one of its superclasses appears. If it finds a
CATCHblock, there are two possible cases:
- If the
BEFORE UNWINDaddition is not declared in the
CATCHstatement, the system first deletes the context in which the exception was raised, including all called procedures and their local data. The
CATCHblock is then executed.
- If the
BEFORE UNWINDaddition is declared in the
CATCHblock is executed immediately. If the
CATCHblock is exited using the
RESUMEstatement in a resumable exception, the program resumes after the place where the exception was raised. In all other cases, the system deletes the context in which the exception was raised, after the
CATCHblock is exited.
CATCHblock is not exited with a statement such as
RETRY, or any other processing block exits, processing continues after the block's
- If no handlers are found in any of the participating
TRYcontrol structures of a protected area, or if the exception is not raised during processing of a
TRYblock of a
TRYcontrol 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 user 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 raised 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
CLEANUPblocks of all
TRYcontrol structures that have thus far been scanned unsuccessfully are executed from the inside to the outside, directly before their context is deleted. This means that, if
BEFORE UNWINDis declared for the
CLEANUPblocks are executed when the handler is exited; otherwise they are executed before being handled. Exceptions that are raised within a
CLEANUPblock cannot exit the block; they must be handled there.
CLEANUPblocks are executed in the following cases:
- When the handling of a
resumable exception is exited with
TRYcontrol structures whose exception is raised in a
CATCHblock is not part of the protected range).
Other versions: 7.31 | 7.40 | 7.54
Class-Based Exceptions in Procedures