Parameter interface of procedures

The parameter interface of a procedure consists of formal parameters and specifies the possible exceptions of the procedure.

Formal parameters

Formal parameters are: input parameters, output parameters, input/output parameters and return values. There are also the obsolete table parameters. Formal parameters are either generic or completely typed. Pass by reference or pass by value can be specified for most formal parameters. Pass by value is mandatory for some formal parameters.

Exceptions

Class-based exceptions can be declared using RAISING for all procedures (methods, function modules, sub-programs), and can then be propagated from the procedure. Also, EXCEPTIONS can be used in methods and function modules to define non-class-based exceptions, which can then be triggered in the procedure using RAISE or MESSAGE ... RAISING.

Pass by reference vs. pass by value.

When deciding whether to use pass by reference or pass by value for a formal parameter, you must compare the relative performance and robustness of each transfer type.

In ABAP, pass by reference always leads to better performance, as no local data object has to be stored and no data transport is necessary when the procedure is called. Therefore, for performance reasons, pass by reference is usually preferable, unless there is an explicit or implicit write access to an input parameter in the procedure or you want to ensure that an input/output parameter or an output parameter is returned only if the procedure ends without any errors. In such cases, pass by value is mandatory; this is so that the assigned actual parameter is not simultaneously modified in the caller when there is a write access to a formal parameter. For performance reasons, only parameters of 100 bytes or less should be transferred in these cases, where possible.

Note the following when using pass by reference:

• In sub-programs, write access can be gained to an input parameter that was defined with USING without the occurrence of syntax errors, which is not the case with method or function module input parameters defined with IMPORTING.

• An output parameter that is passed by reference acts like an input/ output parameter; in other words, if there is a read access to an output parameter in the procedure before the value of that parameter is changed, this value is not initial, unlike with pass by value, but is the same as the current value of the actual parameter in the caller.

• If a procedure is stopped because of an error - that is, if it is stopped for a reason other than that it has reached its last statement or RETURN (or EXIT or CHECK) - all actual parameters that are passed by reference retain the value of the assigned formal parameter that that parameter had when the program was stopped.

Procedures and their calls have to be programmed in such a way that these kinds of errors do not occur.

Therefore, to summarize, pass by reference is always preferable when performance is an issue, while pass by value is more suitable in situations where robustness and data consistency are more important. These considerations have to be taken into account in each individual case when you decide which pass type to use with which type of parameter.

Notes

• When strings or internal tables are passed by value, table sharing comes into force between the locally-created data object and the transferred data object, similarly to with a statement. However, this only happens if the row type of the internal table permits it.

• Only pass by reference can be specified for the obsolete table parameters.

• Pass by value is mandatory for the return value of functional methods, the output parameters of events in ABAP Objects, and all formal parameters of RFC-enabled function modules and update function modules (pass by value is also implicitly used here with table parameters).