Skip to content

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

ASSERT

Quick 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. An assertion is either active or inactive.

  • 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 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.

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. Compared with the implementation with an IF statement and a RAISE SHORTDUMP statement or a conditional expression with THROW SHORTDUMP, the ASSERT statement is shorter, its meaning is immediately recognizable, and it can be activated externally.
  • 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.


Example

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.

Addition 1

... ID group

Effect

The addition ID defines how the statement ASSERT is activated and behaves 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. 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 (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 AS Instance specified
  • Operation mode - System behavior of the various 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 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 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 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 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.


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.
  • 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.


Example

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.

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 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.


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.


Example

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.

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.


Example

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.