ARTICLE
Function Module Interface
The parameter interface of a
function module is defined in Function Builder. It includes the
definition of interface parameters and the specification of exceptions
that can be raised by a function module. Function Builder automatically
generates comment lines below the FUNCTION
statement in the source code of the function module. These represent the
interface of the function module with the following syntax:
Syntax
... [IMPORTING parameters ]
[EXPORTING parameters ]
[TABLES
table_parameters ]
[CHANGING parameters ]
[{RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...}
|{EXCEPTIONS exc1 exc2 ...}]
The syntax and semantics of IMPORTING , EXPORTING ,
CHANGING , RAISING , and EXCEPTIONS mainly correspond to
the definition of method interfaces with
[CLASS-]METHODS . The additional option of defining table
parameters using TABLES is
obsolete.
Note
The ABAP Development Tools do not have a
form-based Function Builder and the parameter interface of a function
module is defined in an ABAP pseudo syntax. These statements are not
compiled like genuine ABAP statements and the regular ABAP syntax checks
are not applied. When a function module is generated, they are
interpreted like the form-based instructions from the classical Function
Builder.
Interface Parameters
The interface parameters are defined on the relevant tab pages in
Function Builder.
IMPORTING parameters are input parameters. When the function
module is called, a suitable actual parameter must be specified for
every non-optional input parameter. The content of the actual parameter
is passed to the input parameter when the call is made. The content of a
n input parameter for which 'pass by reference' is defined cannot be
changed in the function module.
EXPORTING parameters are output parameters. When the function
module is called, a suitable actual parameter can be specified for every
output parameter. The content of an output parameter that is defined for
'pass by value' is passed to the actual parameter if the function module
is completed without errors. An output parameter that is defined for
pass by reference is not initialized when the function module is called.
TABLES parameters are
obsolete table parameters .
CHANGING parameters are input and output parameters. When the
function module is called, a suitable actual parameter must be specified
for every non-optional input or output parameter. When the function
module is called, the content of the actual parameter is passed to the
input/output parameter, and when the function module is completed, the
content of the input/output parameter is passed to the actual parameter.
Note
The formal parameters of a function module can be registered as
global parameters in Function
Builder, however this is obsolete.
Exceptions
The exceptions of a function module are defined on the Exceptions
tab page in Function Builder. Here exception classes can
be selected to define whether
class-based exceptions are declared or
non-class-based exception are defined. Class-based exceptions are
represented in the above syntax by RAISING , and non-class-based
exceptions are represented by EXCEPTIONS .
The addition RAISING is used to declare class-based exceptions
that can be propagated from the function module to the caller.
Exceptions in the categories CX_STATIC_CHECK and
CX_DYNAMIC_CHECK must be explicitly declared, otherwise a propagation
can lead to an interface violation. A violation of the interface raises
the handleable exception CX_SY_NO_HANDLER . Exceptions of the
category CX_NO_CHECK are always declared implicitly and with the
RESUMABLE addition. The declaration of exceptions of the category
CX_STATIC_CHECK is checked statically in the syntax check. For
exceptions of the category CX_DYNAMIC_CHECK , the check is not
performed until runtime. In a function module in which class-based
exceptions are declared with the RAISING addition, the statement
CATCH SYSTEM-EXCEPTIONS cannot be used.
Instead, the relevant handleable exceptions should be handled in a
TRY control structure.
The RESUMABLE addition declares an exception that can be
propagated as a resumable exception
. This addition has no relevance to a non-resumable exception. The
addition does not have any effect on a non-resumable exception. If a
resumable exception is propagated with RAISING without the
addition RESUMABLE , it thus becomes non-resumable. If a
superclass is declared as resumable, any subclasses must also be
declared as resumable.
The addition EXCEPTIONS is used to define a list of
non-class-based exceptions that can be raised in the function module
using the statements RAISE or
MESSAGE RAISING . Exceptions defined
in this way are (as with formal parameters) bound to the function module
and cannot be propagated. If an exception of this type is raised in a
function module, and no return value has been assigned to it with the
homonymous addition EXCEPTIONS of the
CALL FUNCTION statement when the call was made, this leads to a
runtime error. In a function module in whose interface non-class-based
exceptions are defined, the statement
RAISE EXCEPTION or the addition
THROW in a
conditional expression cannot be
used to raise class-based exceptions.
The Resumable column in Function Builder can be selected
to flag a class-based exception as a
resumable exception . This places
the RESUMABLE addition behind RAISING in the syntax above.
Note
For new developments, SAP recommends working with class-based exceptions
that are independent of the function module.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved