ASSERT [ [ID group [SUBKEY sub]]
[FIELDS val1 val2 ...]
CONDITION ] log_exp.
Without the addition
ID, the assertion is always active.
When using addition
ID, the activation and the behavior of the statement are controlled from outside the program by means of a checkpoint group.
When the program reaches an active assertion, the logical expression is evaluated and the program execution
continues from the statement after
ASSERT only if the result of
is true. After an inactive assertion, the logical expression
log_exp is not evaluated and the program execution continues at the statement after
If the result of
log_expis false, a non-handleable exception is raised for an assertion that is always active (without the addition
ID) and the program terminates with the runtime error ASSERTION_FAILED.
For an assertion activated externally (with the addition
IDspecified), the operation mode specified for a checkpoint group or the current compilation unit determines how the program execution is continued.
Assertions help verify particular assumptions about the state of a program in a particular location
and ensure that these assumptions are maintained. Compared with the implementation with an
IFstatement and a
RAISE SHORTDUMPstatement or a conditional expression with THROW SHORTDUMP, the
ASSERTstatement is shorter, its meaning is immediately recognizable, and it can be activated externally.
If functional methods are specified as operands of a
in the logical expression
log_exp, they must be free of side effects. This must especially be the case for assertions that can be activated externally, since the program behavior is otherwise dependent on activation.
Before a dynpro is called, the statement
ASSERT ensures that a SAP GUI exists. If this is not the case, the program cancels with the runtime error ASSERTION_FAILED.
DATA gui_flag TYPE abap_bool. CALL FUNCTION 'GUI_IS_AVAILABLE' IMPORTING return = gui_flag. ASSERT gui_flag = abap_true. CALL SCREEN 100.
... ID group
ID defines how the statement
ASSERT is activated and behaves outside of the program using the
group. If the addition
ID is specified, the addition
CONDITION must be specified before the
log_exp logical expression.
The name of the checkpoint group must be specified directly and the group must exist in the repository. A checkpoint group is managed using the transaction SAAB. In a checkpoint group, activation settings can be made for the assigned checkpoints either directly or using activation variants.
All checkpoint statements associated with the checkpoint group
can be activated or deactivated from the checkpoint group. An activation setting consists of the following components:
- Validity area - Checkpoints specified in the checkpoint group or compilation unit
- Context - User and/or AS Instance specified
Operation mode - System behavior of the various checkpoint types (assertions, breakpoints, or logpoints)
The following settings are possible:
The assertion is inactive.
Creates an entry in a special log and continues program execution with the statement after
ASSERT. The log entries are collected in the shared memory and are written periodically in a database table by a background job. By default, any existing entries of the same
ASSERTstatement are overwritten. Each time an entry is written, a counter for the entry is incremented. The log can be evaluated using transaction SAAB .
- stop / log or stop / cancel
Go to the ABAP Debugger. In dialog processing, the statement
ASSERTbehaves like the statement
BREAK-POINT. The setting specified as alternative is used for the cases in which the statement
BREAK-POINTwrites an entry in the system log, namely for background sessions, update sessions, ICF sessions, and APC sessions without external debugging.
Raise an unhandleable exception and terminate the program with runtime error ASSERTION_FAILED.
If the checkpoint statements are activated from the compilation unit, then the association with a specific checkpoint group no longer has any meaning.
If the checkpoint statements are activated from the compilation unit, it is necessary to specify a checkpoint group, since a checkpoint statement without the addition
IDis always active.
- The validity period of activation settings with active operation modes is limited.
LOG-POINTcan be used to define a logpoint if entries are to be written to a log. The statement
ASSERTshould not be used for this purpose.
Like the previous example, but here the behavior of the statement
ASSERT is specified using the checkpoint group DEMO_CHECKPOINT_GROUP.
DATA gui_flag TYPE abap_bool. CALL FUNCTION 'GUI_IS_AVAILABLE' IMPORTING return = gui_flag. ASSERT ID demo_checkpoint_group CONDITION gui_flag = abap_true. CALL SCREEN 100.
... SUBKEY sub
SUBKEY only takes effect if the statement
writes entries to a log. If
SUBKEY is specified, the content of
is stored in the log as a subkey. Any existing log entries of the same
statement are overwritten only if the subkey has the same content. If
SUBKEY is not specified, the subkey is initial.
sub is a
character-like expression position of which the first 200 characters are evaluated. An expression or function specified here is evaluated only if the assertion is active and the logical expression is false.
... FIELDS val1 val2 ...
After the addition
FIELDS, a list
val1 val2 ...
of any values (except reference variables) can be specified. If the statement
writes entries to a log, the content of the data objects
val1 val2 ... is
included in the log. If an non-handleable exception is raised, the content of the first eight specified data objects is displayed in the associated
short dump. The addition
FIELDS is ignored when a jump to ABAP Debugger is performed.
val1 val2 ... are
functional operand positions in which data objects or functional methods can be specified. The methods are executed only if the assertion is active and the logical expression is false.
If the addition
FIELDS is specified, the addition
CONDITION must be specified before the
log_exp logical expression.
- The log to which assertions write is not the system log to which breakpoints write during background processing. It is a special log that can be read in transaction SAAB .
The size of each data object saved in the log with the
FIELDSaddition is restricted by the profile parameter abap/aab_log_field_size_limit. The value of the profile parameter specifies the size in bytes. The default value is 1,024. The value 0 means there is no restriction. When a log entry is generated, the content of each data object is truncated when this limit is reached, and full lines are removed from internal tables.
If functional methods are specified after
FIELDS, code for formatting log entries can be executed only after an assertion is violated.
Like the previous example, but here logs are provided with additional information.
DATA gui_flag TYPE abap_bool. CALL FUNCTION 'GUI_IS_AVAILABLE' IMPORTING return = gui_flag. ASSERT ID demo_checkpoint_group SUBKEY sy-uname FIELDS 'Missing GUI' sy-binpt CONDITION gui_flag = abap_true. CALL SCREEN 100.
CONDITION triggers the logical expression. It has to be specified
log_exp if one of the other additions is specified; otherwise, it can be omitted.
Like the first example above, but here the optional
CONDITION addition is specified. .
DATA gui_flag TYPE abap_bool. CALL FUNCTION 'GUI_IS_AVAILABLE' IMPORTING return = gui_flag. ASSERT CONDITION gui_flag = abap_true. CALL SCREEN 100.