ASSERT

Short Reference

Syntax

ASSERT [ [ID group [SUBKEY sub]]
         [FIELDS dobj1 dobj2 ...]
         CONDITION ] log_exp.

Extras:

1. ... ID group

2. ... SUBKEY sub

3. ... FIELDS dobj1 dobj2 ...

4. ... CONDITION

Effect

This statement defines an assertion. For log_exp, you can specify any logical expression. When the program reaches an active assertion, the logical expression is evaluated and the program execution continues with the next statement after ASSERT only if the result of log_exp is true. If an assertion is inactive, the logical condition log_exp is not evaluated and the program execution continues with the next statement after ASSERT.

If the result of log_exp is false, for an always active assertion (without the addition ID) an untreatable exception is triggered and the program terminates with the runtime error ASSERTION_FAILED.

For an assertion activated from the outside (with addition ID specified), the opertaion 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.
  
  
• logging
  
  Creating an entry in a specific protocol and continuation of the program execution with the statement after ASSERT. By default, an existing entry of the same ASSERT statement is overwritten. You can use transaction SAAB to evaluate the log.
  
  
• stop / log or stop / cancel
  
  Switching to the ABAP Debugger. In the dialog processing, the statement ASSERT behaves as 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 protocol, that means, for background processing, synchronous or asynchronous logging, or HTTP sessions without external debugging.
  
  
• cancel
  
  
• Triggering an untreatable exception and terminating the program with runtime error ASSERTION_FAILED.
  
  
  

Note

Assertions are used to verify specific assumptions about the status of a program at a specific point and to ensure that these 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.

• Since release 7.0, you can use the statement LOG-POINT to define a logpoint if you want to implicitly write entries in a protocol. You should not use the statement ASSERT for this purpose.
  
  
  

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.

Addition ID assigns the assertion to a checkpoint group group. You must specify the name of the checkpoint group directly and the group must exist in the repository. To administer a checkpoint group, use transaction SAAB. For a checkpoint group, activation settings can be made for the assigned checkpoints either directly or using activation variants.

All checkpoint statements linked linked to the checkpoint group (ASSERT, BREAK-POINT, LOG-POINT) can be activated or deactivated via the checkpoint group. An activation setting consists of three components:

• Validity area - Specification of the checkpoints via checkpoint group or compilation unit
  
• Context - Specify user and/or application server
  
• Operation mode - System behaviour of the several checkpoint types (Assertions, Breakpoints or Logpoints)
  

When the activation of checkpoint statements is carried out via the compilation unit, then the link to a certain checkpoint group is of no importance.

Note

When activating via the compilation unit, it is necessary to specify a checkpoint group, as a checkpoint statement without the addidtion ID is always active.

Addition 2

... SUBKEY sub

Effect

Addition SUBKEY only takes effect if the statement ASSERT writes entries to a log. When specifying SUBKEY, the content of sub is stored in the log as a subkey. Existing log entries of the same ASSERT statement are overwritten only if the subkey has the same content. For sub, you must specify a character-type data object, of which the first 200 characters are evaluated. If you do not specify SUBKEY, the subkey is initial.

Addition 3

... FIELDS dobj1 dobj2 ...

Effect

After addition FIELDS, you can specify a list dobj1 dobj2 ... of any data objects, except reference variables. If the statement ASSERT writes entries to a log, the content of the data objects dobj1 dobj2 ... is included into the log. If an untreatable exception is triggered, the content of the first eight specified data objects is displayed in the corresponding short dump. If you switch to the ABAP debugger, the FIELDS addition has no effect.

If the addition FIELDS is specified, the addition CONDITION must be specified before the logical expression log_exp.

Notes

• The log to which assertions write is not the systen log to which breakpoints write during background processing. It is a special log that can be read in transaction SAAB.
  
• The size of each of the data objects stored in the log with the FIELDS addition is limited by the profile parameter abap/aab_log_field_size_limit. The value of the profile parameter specifies the size in bytes. The preset value is 1024. A value of 0 means no restriction. When a log entry is created, the content of each data object is truncated at the specified length; in internal tables, complete rows are removed.
  
  
  

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.