Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Program Layout →  Modularization Statements →  Procedures →  Function Modules →  FUNCTION 

Function Module Interface

The parameter interface of a function module is defined in Function Builder or in the ABAP Development Tools (ADT). It includes the definition of interface parameters and the specification of exceptions that can be triggered by a function module. ADT uses an editor with statements in ABAP pseudo syntax and Function Builder creates comment lines automatically underneath the statement FUNCTION in the source code of a function module , which represent the interface of the function module as follows:

Other versions: 7.31 | 7.40 | 7.54


... [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 using [CLASS-]METHODS. The additional option of defining table parameters using TABLES is obsolete.


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 classic Function Builder.

Interface Parameters

The interface parameters are defined in ADT in ABAP pseudo syntax and defined in Function Builder on the appropriate tabs .

  • 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 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 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.
  • 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.


The formal parameters of a function module can be registered as global parameters in Function Builder, however this is obsolete.


In ADT, the exceptions of a function modules are defined in ABAP pseudo syntax or on the Exceptions tab 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 addition RESUMABLE. 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 using the addition RAISING, the obsolete statement CATCH SYSTEM-EXCEPTIONS cannot be used to handle catchable runtime errors. Instead, the handleable exceptions assigned to the runtime errors should be handled in a TRY control structure.

    The addition RESUMABLE 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 in RAISING and the addition RESUMABLE is not specified, 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 was assigned to it with the identically named addition EXCEPTIONS of the statement CALL FUNCTION when the call was made, a runtime error is produced. 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 addition RESUMABLE behind RAISING in the syntax above.


  • For new developments, SAP recommends that you work with class-based exceptions that are independent of the function module.


Comment lines generated by Function Builder for various categories of actual parameters and a class-based resumable exception of a function module.

*"*"Local Interface: 


Properties of Interface Parameters