SAP RUNTIME ERROR DYN PROC - Guide

Get Example source ABAP code based on a different SAP table
  SAP Help

Warning: Undefined variable $prev in /customers/b/9/9/trailsap.com/httpd.www/sap-help/index.php on line 54
GUIDELINE 6.47

Runtime Errors in Dynamic Processing

ABAP_BACKGROUND
When dynamic techniques are used, various exception situations can arise that can never occur when the corresponding static techniques are used because they can be checked statically.

ABAP_RULE
Preventing Runtime Errors in Dynamic Processing
Respond appropriately to all possible error situations when using dynamic techniques.

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

When dynamic data objects are accessed, their limitations must not be violated. For internal tables, for example, no row numbers must be specified for which no row exists.

Before data objects are accessed dynamically by using data references or field symbols, it must be ensured, before execution, that these are bound to a data object and this binding checked using IS BOUND or IS ASSIGNED, if necessary. Afterwards, the return value should be checked to see whether execution was successful.

In dynamic calls, exceptions must be caught that are raised due to nonexistent programs, classes, or procedures, or due to inappropriate parameters.

In the case of a dynamically specified token, for example, a dynamic WHERE condition in Open SQL or internal tables, possible exceptions must be caught and responded to accordingly.

If programs are developed generically, the programs in question must checked using the statement SYNTAX-CHECK.
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, dynamic programming techniques must always be used with care.

Note
If it is not possible to particular error situations, for example, because no exception that can be handled exists, it must be ensured that this error situation never occurs and this then verified 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>.
ASSIGN where_clauses[ ... ] TO <(><<)>where_clause>.
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.