hi chk this
ASSERT
Basic form
ASSERT [ID group [SUBKEY sub]
[FIELDS dobj1 dobj2 ...] CONDITION]
log_exp.
Extras:
1. ... ID group
2. ... SUBKEY sub
3. ... FIELDS dobj1 dobj2 ...
Effect
<b>This statement defines a conditional checkpoint (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 is only continued with the statement after ASSERT if the result of log_exp is true. In the case of an inactive assertion, the logical condition log_exp is not evaluated and the program execution is continued with the statement after ASSERT.
If the result of log_exp is incorrect, an exception that cannot be handled is raised for a permanently active assertion (when the ID addition is not specified) and the program is terminated with the runtime error ASSERTION_FAILED.</b>
In the case of an assertion activated from the outside (when the ID addition is specified), the activation mode specified in the checkpoint group defines the subsequent program execution. The possible settings are:
Create an entry in a special log and contine program execution with the statement after ASSERT. By default, an existing entry of the same ASSERT statement is overwritten. You can evaluate the log using the transaction SAAB.
Branch to the ABAP Debugger. This setting only works in dailog processing. For background processing and update, one of the two other settings must be specified as an alternative.
Raise an exception that cannot be handled and terminate the program with the runtime error ASSERTION_FAILED.
Addition 1
... ID group
Effect
Without the ID addition, the assertion is always active. If you use the ID addition, the activation and behavior of the statement is controlled from outside the program by a checkpoint group.
The ID addition assigns the assertion to a checkpoint group group. The name of the checkpoint group must be specified directly and it must be in the Repository. A checkpoint group is managed using the transaction SAAB. It contains the activation settings for the checkpoints assigned to it; assertions and breakpoints are handled separately.
The activation settings of a checkpoint group activate or deactivate the assigned assertions and breakpoints within validitiy areas that you can define. Possible validity areas are user, application server, SAP System, and so on.
Addition 2
... SUBKEY sub
Effect
The SUBKEY addition only works if the ASSERT statement writes entries into a log. If you specify SUBKEY the content of sub is stored in the log as a subkey. Existing log entries of the same ASSERT statement are only overwritten if the content of the subkey is the same. 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 the FIELDS addition, you can specify a list of flat data objects dobji. If the ASSERT statement writes entries into a log, the contents of the data objects dobji are also copied into the log. If an exception that cannot be handled is raised, the contents of the first 8 specified data objects is displayed in the corresponding short dump. If you branch to the ABAP Debugger, the FIELDS addition is ineffective.
Notes
<b>Assertions are used to verify assumptions about the state of a program at a specific point and ensure that these are observed. In comparison with implementation using an IF statement and an exit message , for example, the ASSERT statement is shorter, its meaning is immediately apparent, and it can be activated from the outside..</b>
The log into which assertions write is not the system log into which breakpoints write during background processing.
Bluesky
