ARTICLE
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 using the statement
RAISE EXCEPTION or the addition
THROW in a
conditional expression .
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 TRY block of a
TRY control structure is executed, 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 exception is raised, 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, there are two
possible cases:
If the addition BEFORE UNWIND is not declared in the statement
CATCH , the context in which the exception
was raised is first deleted, including all called procedures and their
local data. The CATCH block is then executed.
If the addition BEFORE UNWIND is declared in the statement
CATCH , the CATCH block is executed
immediately. If the CATCH block is exited using the statement
RESUME 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 CATCH block is exited.
If the CATCH block is not exited with a statement such as
RESUME , RETRY , or any
other processing block exits ,
processing continues after the block's TRY control structure.
If no handlers are found in any of the participating TRY control
structures of a protected area, or if the exception is not raised 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 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 CLEANUP blocks of
all TRY control 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 UNWIND
is declared for the CATCH block, the CLEANUP blocks
are executed when the handler is exited; otherwise they are executed
before being handled. Exceptions that are raised within a CLEANUP
block cannot exit the block; they must be handled there.
No CLEANUP blocks are executed in the following cases:
When the handling of a resumable
exception is exited with RESUME .
TRY control structures whose exception is raised in a CATCH
block (a CATCH block is not part of the protected range).
See also:
Class-Based Exceptions in Procedures
Class-Based Exceptions in Event Handlers
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved