Get Example source ABAP code based on a different SAP table
• IMPORTING FUNCTION • EXPORTING FUNCTION • CHANGING FUNCTION • RAISING FUNCTION • RESUMABLE FUNCTION • EXCEPTIONS FUNCTION
Function Module Interface The parameter interface> of a function module is defined BEGIN_SECTION VERSION 5 OUT in the Function Builder or END_SECTION VERSION 5 OUT in the ABAP Development Tools (ADT)>. It comprises the definition of interface parameters and the specification of exceptions that can be raised by a function module. ADT uses an editor with statements in ABAP pseudo syntax BEGIN_SECTION VERSION 5 OUT and the Function Builder automatically creates comment lines below the statement FUNCTION>> in the source code of a function module END_SECTION VERSION 5 OUT , which represent the interface of the function module as follows:
ABAP_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.
Latest notes: In the ABAP Development Tools> the parameter interface of a function module is defined in ABAP pseudo syntax. These statements are not compiled like genuine ABAP statements and are not subject to the regular ABAP syntax checks. NON_V5_HINTS They are interpreted like the form-based instructions of the classic Function Builder when a function module is generated. ABAP_HINT_END
Interface Parameters The interface parameters are defined in the ADT in ABAP pseudo syntax BEGIN_SECTION VERSION 5 OUT and in the Function Builder on the corresponding tab pages END_SECTION VERSION 5 OUT .
IMPORTING> parameters are input parameters. When the function module is called, a suitable actual parameter must be specified for each non-optional input parameter. The content of the actual parameter is passed to the input parameter when it is called. The content of an 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 each 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 each non-optional input or output parameter. The content of the actual parameter is passed to the input/output parameter when the parameter is called, and the content of the input/output parameter is passed to the actual parameter when the function module is completed.
Latest notes: NON_V5_HINTS The formal parameters of a function module can be registered as global parameters> in the Function Builder. However, this is obsolete. ABAP_HINT_END
Exceptions The exceptions of a function module are defined in the ADT in ABAP pseudo syntax BEGIN_SECTION VERSION 5 OUT or on the Exceptions> tab in the Function Builder END_SECTION VERSION 5 OUT . When exception classes> are selected, it is specified whether it is a declaration of a class-based exception> or a non-class-based exception>. 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 of the categories CX_STATIC_CHECK> and CX_DYNAMIC_CHECK> must be declared explicitly, otherwise a propagation leads to an interface violation. A violation of the interface raises the catchable exception CX_SY_NO_HANDLER>. Exceptions of the category CX_NO_CHECK> are always declared implicitly with the addition RESUMABLE>, but they can also be declared explicitly. The declaration of exceptions of the category CX_STATIC_CHECK> is checked statically during syntax check. For exceptions of the category CX_DYNAMIC_CHECK>, the check is not performed until runtime. For exceptions of the category CX_NO_CHECK > no check is performed. BEGIN_SECTION VERSION 5 OUT In a function module in which class-based exceptions are declared using the addition RAISING>, the obsolete statement CATCH SYSTEM-EXCEPTIONS>> cannot be used to handle catchable runtime errors>. Instead, the catchable exceptions assigned to the runtime errors are intended to be handled in a TRY>> control structure. END_SECTION VERSION 5 OUT The addition RESUMABLE> declares an exception so that it can be propagated as a resumable exception >, which is then also propagated as such. The addition has no effect on a non-resumable exception. If a resumable exception is propagated in RAISING> without the additionRESUMABLE>, it becomes non-resumable. If a superclass is declared as resumable, all of the simultaneously listed subclasses must also be declared as resumable. BEGIN_SECTION ID FUNCTION-EXCEPTIONS
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 bound to the function module, similarly to formal parameters, and cannot be propagated. If such an exception is raised in a function module, and no return value was assigned to it with the identically named addition EXCEPTIONS> of the statement CALL FUNCTION>> during the call, a runtime error occurs. 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. END_SECTION ID FUNCTION-EXCEPTIONS BEGIN_SECTION VERSION 5 OUT For class-based exceptions, the Resumable> column can be selected in the Function Builder to mark a class-based exception as a resumable exception>. This places the addition RESUMABLE> behind RAISING> in the syntax above. END_SECTION VERSION 5 OUT
ABAP_PGL Using Class-Based Exceptions> For new developments, it is recommended that class-based exceptions that are independent of individual function modules are used. ABAP_PGL_END
Latest notes: See also Class-Based Exceptions in Procedures>. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Comment lines generated by the tools for different types of actual parameters and a class-based resumable exception of a function module. ABEXA 01041 ABAP_EXAMPLE_END