ABAP Keyword Documentation → ABAP Programming Guidelines → Robust ABAP → Dynamic Programming Techniques

Runtime Errors in Dynamic Processing

Other versions: 7.31 | 7.40 | 7.54

Background

When you use dynamic techniques, various exception situations can arise that can never occur when you use the corresponding static techniques because of their static checkability.

Rule

Preventing Runtime Errors in Dynamic Processing

Respond appropriately to all possible error situations when using dynamic techniques.

Details

The different dynamic techniques also require different reactions to the possible exception situations. Examples:

When accessing dynamic data objects, you must not violate their limitations. For internal tables, for example, you must not specify line numbers for which no line exists.

Before dynamically accessing data objects by using data references or field symbols, you must ensure before execution that these are connected to a data object and check this connection using IS BOUND or IS ASSIGNED, if necessary. After the access, you should check the return value for a successful execution, if possible.

For the dynamic invoke, you must catch exceptions that are triggered due to non-existent programs, classes, or procedures or due to inappropriate parameters.

In case of a dynamic token specification, for example, a dynamic WHERE condition in Open SQL or internal tables, you must catch possible exceptions and respond accordingly.

If programs are generically developed, you have to check the generated programs using the SYNTAX-CHECK statement.

These examples illustrate how the use of dynamic techniques can lead to more complex and less clear code due to the numerous possible exception situations. Of course, the more the mentioned techniques are combined, the more complex and less clear the code becomes. Therefore, you should always use dynamic programming techniques with care.

Note

If you cannot respond to particular error situations, for example, because no exception that can be handled exists, you must ensure that this error situation never occurs and verify this in extensive test scenarios.

Bad example

The seemingly legible source code section uses almost only dynamic operands and tokens. Neither the ABAP Compiler nor the reader can know the content of the specified variables at runtime. An error in one of these variables results in a termination of the program.

READ TABLE where_clauses ASSIGNING <where_clause> WITH ...
DELETE FROM (dbtab_name) WHERE (<where_clause>).
IF sy-subrc = 0.
CALL METHOD (class_name)=>(method_name).
ENDIF.

Good example

The following source code corrects the above example with an appropriate error handling # this reduces the legibility, of course. Here, it is additionally considered that an initial dynamic WHERE condition means that no restrictions are imposed. As shown here, this case must be explicitly avoided. Otherwise, the entire table content will be deleted.

UNASSIGN <where_clause>.
READ TABLE where_clauses ASSIGNING <where_clause> WITH ...
IF sy-subrc <> 0.
   RAISE EXCEPTION ...
ENDIF.
ASSERT <where_clause> IS ASSIGNED.
IF <where_clause> IS NOT INITIAL.
   TRY.
       DELETE FROM (dbtab_name) WHERE (<where_clause>).
     CATCH cx_sy_dynamic_osql_error.
       ...
   ENDTRY.
   IF sy-subrc = 0.
      TRY.
            CALL METHOD (class_name)=>(method_name).
          CATCH cx_sy_dyn_call_error.
            ...
       ENDTRY.
   ENDIF.
ENDIF.