What does it do? This statement defines an assertion>. Any logical expression> can be specified for log_exp>>. An assertion is either active or inactive.
Without the addition ID>, the assertion is always active.
When using the addition ID>, the activation and the behavior of the statement are controlled from outside the program by a checkpoint group>. When the program reaches an active assertion, the logical expression is evaluated, and the program execution continues with the statement after ASSERT> only if the result of log_exp> is true. After an inactive assertion, the logical expression log_exp> is not evaluated and the program execution continues with the statement following ASSERT>.
If the result of log_exp> is false, an uncatchable exception is raised for an assertion that is always active, if the addition ID> is not specified, and the program terminates with the runtime error ASSERTION_FAILED >.
For an assertion activated externally, if the addition ID> is specified, the operation mode specified for a checkpoint group> or the current compilation unit> determines how the program execution is continued.
ABAP_PGL Using Assertions> ABAP_PGL_END
Latest notes:
If functional methods> are specified as operands of a relational expression> in the logical expression log_exp>, they must not have any side effects. This must especially apply to assertions that can be activated externally, since the program behavior otherwise depends on the activation.
Assertions help verify certain assumptions about the state of a program in a particular location and ensure that these assumptions are met. Compared with the implementation with a conditional expression with THROW SHORTDUMP>>, the ASSERT> statement is shorter, its meaning is immediately recognizable, and it can be activated externally. NON_V5_HINTS
This is also true in comparison with an IF> statement and a RAISE SHORTDUMP>> statement. ABAP_HINT_END
ABAP_EXAMPLE_VX Before a dynpro is called, the statement ASSERT> ensures that a SAP GUI exists. If this is not the case, the program terminates with the runtime error ASSERTION_FAILED>. ABEXA 00011 ABAP_EXAMPLE_END
ABAP_EXAMPLE_V5 The statement ASSERT> ensures a certain condition that is necessary for its continuation. If this is not the case, the program terminates with the runtime error ASSERTION_FAILED>. ABEXA 01619 ABAP_EXAMPLE_END • ID ASSERT
ABAP Addition
What does it do? The addition ID> defines that the activation of the statement ASSERT> is controlled from outside of the program using the checkpoint group> 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>. BEGIN_SECTION VERSION 5 OUT A checkpoint group is managed using the transaction SAAB>>. For a checkpoint group, activation settings can be specified for the assigned checkpoints either directly or using activation variants>. END_SECTION VERSION 5 OUT All checkpoint statements linked with the checkpoint group ( ASSERT>, BREAK-POINT>, LOG-POINT>) can be activated or deactivated using the checkpoint group. An activation setting consists of three components:
Validity area - Checkpoints specified in the checkpoint group or compilation unit>
Context - User and/or ABAP_ASINSTANCE specified
Operation mode - System behavior of the different checkpoint types (assertions, breakpoints, or logpoints) The following settings are possible:
Inactive>
The assertion is inactive.
Log>
Creates an entry in a special log and continues program execution with the statement following ASSERT>. The log entries are collected in the shared memory and are written to a DDIC database table by a periodical background job. By default, any existing entries of the same ASSERT> statement are overwritten. Each time an entry is written, a counter for the entry is increased. BEGIN_SECTION VERSION 5 OUT The log can be evaluated using transaction SAAB>>. END_SECTION VERSION 5 OUT
stop / log> or stop / cancel>
Branch to the ABAP Debugger. BEGIN_SECTION VERSION 5 OUT In dialog processing>, the statement ASSERT> behaves like the statement BREAK-POINT>>. The specified alternative setting is used for the cases in which the statement BREAK-POINT> writes an entry to the system log, namely for background sessions >, update sessions>, ICF> sessions, and APC> sessions without external debugging. END_SECTION VERSION 5 OUT
Cancel>
Raising of an uncatchable exception and terminating the program with the runtime error ASSERTION_FAILED>. If the checkpoint statements are activated using the compilation unit, then the association with a specific checkpoint group no longer has any meaning.
Latest notes:
If the checkpoint statements are activated using the compilation unit, a checkpoint group must still be specified, since a checkpoint statement without the addition ID> is always active.
The validity period of activation settings with active operation modes is limited. NON_V5_HINTS
The statement LOG-POINT>> can be used to define a logpoint> if entries are to be written to a log. The statement ASSERT> should not be used for this purpose. ABAP_HINT_END
ABAP_EXAMPLE_VX Like the previous example, but here the behavior of the statement ASSERT> is controlled using the checkpoint group DEMO_CHECKPOINT_GROUP>. ABEXA 00012 ABAP_EXAMPLE_END
ABAP_EXAMPLE_V5 Like the previous example, but here the behavior of the statement ASSERT> is controlled using the checkpoint group DEMO_CHECKPOINT_GROUP>. ABEXA 01620 ABAP_EXAMPLE_END • SUBKEY ASSERT
ABAP Addition
What does it do? The addition SUBKEY> only has an effect if the statement ASSERT> writes entries to a log. If SUBKEY> is specified, the content of sub> is stored in the log as a subkey. Any existing log entries of the same ASSERT> 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 ASSERT
ABAP Addition
What does it do? After the addition FIELDS>, a list val1 val2 ...> of any values, except for reference variables, can be specified. If the statement ASSERT> writes entries to a log, the specified values val1 val2 ...> are also included in the log. If an uncatchable 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 branch to the 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.
Latest notes:
If functional methods are specified after SUBKEY> and FIELDS >, code for formatting log entries can be executed only after an assertion is violated. NON_V5_HINTS