ASSERT - ABAP Keyword Documentation

ABAP - Keyword Documentation → ABAP - Reference → program editing → Testing and Checking Programs → Checkpoints →

ASSERT

Syntax

ASSERT [ [ID group [SUBKEY sub]]
[FIELDS val1 val2 ...]
CONDITION ] log_exp.

Extras:

1. ... ID group

2. ... SUBKEY sub

3. ... FIELDS val1 val2 ...

4. ... CONDITION

Effect

This statement defines an assertion. Any logical expression can be specified for log_exp. 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 log_exp is true. After an inactive assertion, the logical expression log_exp is not evaluated and the program execution continues at the statement after ASSERT.

If the result of log_exp is 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 ID specified), the operation mode specified for a checkpoint group or the current compilation unit determines how the program execution is continued. The following settings are possible:

Inactive

The assertion is inactive.
Log

Create an entry in a special log and continue 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 ASSERT statement is 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 ASSERT behaves like the statement BREAK-POINT. The setting specified as alternative is used for the cases in which the statement BREAK-POINT writes an entry in the system log, namely for background sessions, update sessions, ICF sessions, and APC sessions without external debugging.
Cancel

Raise a non-handleable exception and terminate the program with runtime error ASSERTION_FAILED.

Programming Guideline

Using Assertions

Notes

Assertions help verify particular assumptions about the state of a program in a particular location and ensure that these assumptions are maintained. Unlike implementation with an IF statement and, for example, an exit message, the statement ASSERT is shorter, its meaning is known directly and it can be activated externally.
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.
If functional methods are specified as operands of a relational expression 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.

Addition 1

... ID group

Effect

Without 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. If the addition ID is specified, the addition CONDITION must be specified before the log_exp logical expression.

The addition ID assigns the assertion to a checkpoint group group. The name of the checkpoint group must be specified directly and the group must exist in the repository. To administer a checkpoint group, use 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 (ASSERT, BREAK-POINT, LOG-POINT) 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 application server specified
Operation mode - System behavior of the various checkpoint types (assertions, breakpoints, or logpoints)

If the checkpoint statements are activated from the compilation unit, the association with a specific checkpoint group no longer has any meaning.

Notes

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 ID is always active.
The validity period of activation settings with active operation modes is limited.

Executable Example

Checkpoints and Checkpoint Groups.

Addition 2

... SUBKEY sub

Effect

The addition SUBKEY only takes 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.

Addition 3

... FIELDS val1 val2 ...

Effect

After the addition FIELDS, a list val1 val2 ... of any values (except reference variables) can be specified. If the statement ASSERT 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 at 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.

Notes

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 FIELDS addition 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 SUBKEY and FIELDS, code for formatting log entries can be executed only after an assertion is violated.

Addition 4

... CONDITION

Effect

The addition CONDITION triggers the logical expression. It has to be specified before log_exp if one of the other additions is specified; otherwise, it can be omitted.