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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved