Skip to content

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

ASSERT

Short Reference

Other versions: 7.31 | 7.40 | 7.54

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, an unhandleable 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, therefore for background processing, synchronous or asynchronous logging, or HTTP sessions without external debugging.
  • Cancel

    Raise an unhandleable 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 ASSERT statement is shorter, its meaning is instantly recognizable, and it can be activated externally.
  • The statement LOG-POINT can be used to to define a log point 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 ID addition is specified, the CONDITION addition 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, then 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.


Example

See 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 unhandleable 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 FIELDS addition is specified, the CONDITION addition 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 CONDITION addition 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.