CALL FUNCTION - parameter_list

Syntax

... [EXPORTING  p1 = a1 p2 = a2 ...]
    [IMPORTING  p1 = a1 p2 = a2 ...]
    [CHANGING   p1 = a1 p2 = a2 ...]
    [TABLES     t1 = itab1 t2 = itab2 ...]
    [EXCEPTIONS [exc1 = n1 exc2 = n2 ...]
                [error_message = n_error]
                [OTHERS = n_others]].

Extras:

1. ... EXPORTING p1 = a1 p2 = a2 ...

2. ... IMPORTING p1 = a1 p2 = a2 ...

3. ... CHANGING p1 = a1 p2 = a2 ...

4. ... TABLES t1 = itab1 t2 = itab2 ...

5. ... EXCEPTIONS exc1 = n1 exc2 = n2 ...

6. ... error_message = n_error

7. ... OTHERS = n_others

Effect

With the exception of the EXCEPTIONS addition, these additions assign the actual parameters a1, a2, ... to the formal parameters p1, p2, ... and t1, t2, ... to the parameter interface of the function module in func. All data objects whose data type suits the typing of the appropriate formal parameter can be specified as actual parameters (refer also to Typing Syntax). Each formal parameter, when the call is made, adopts all the properties of the assigned actual parameter. The EXCEPTIONS addition allows non-class-based exceptions to be handled.

In Unicode programs, an exception that cannot be handled occurs whenever an incorrect formal parameter and the name of the function module are specified by a constant or as a literal. If the name of the function module is specified by a variable and is in non-Unicode programs, the specification of an incorrect formal parameter is ignored.

Addition 1

... EXPORTING p1 = a1 p2 = a2 ...

Addition 2

... IMPORTING p1 = a1 p2 = a2 ...

Addition 3

... CHANGING p1 = a1 p2 = a2 ...

Effect

The additions EXPORTING, IMPORTING, and CHANGING assign actual parameters to the input, output, and input/output parameters of the called function module. Syntax and meaning of these additions are the same as for CALL METHOD.

Addition 4

... TABLES t1 = itab1 t2 = itab2 ...

Effect

With the addition TABLES, internal tables itab1, itab2, ... must be assigned to all non-optional table parameters t1, t2, ... of the called function module. For itab1, itab2, ... , only standard tables can be specified. The transfer takes place by reference (with the exception of RFC). If a specified table itab1, itab2, ... has a header line, this is also transferred. Otherwise, the header line of the corresponding table parameter t1, t2, ... is initial after the call.

Addition 5

... EXCEPTIONS exc1 = n1 exc2 = n2 ...

Addition 6

... error_message = n_error

Addition 7

... OTHERS = n_others

Effect

Using EXCEPTIONS, return values can be assigned to non-class-based exceptions exc1, exc2, ... Syntax and meaning of the addition are the same as for CALL METHOD - with the exception that a predefined exception error_message can be specified here. If no exception occurs, a function module call sets sy-subrc to 0.

If the error_message addition is specified after EXCEPTIONS, all MESSAGE statements that are executed during the processing of the function module and do not have the RAISING addition are affected as follows:

Messages of the type S, I, or W are not sent but are noted in the log background processing.
Messages of the type E and A trigger the exception error_message and set sy-subrc to n_error. The message class, message type, message number, and the contents of possible placeholders for the MESSAGE statement are in the fields sy-msgid, sy-msgno, sy-msgty, and sy-msgv1, ... , sy-msgv4. With messages of the type A, the ROLLBACK WORK statement is also explicitly executed.
Messages of the type X are not influenced. As always, they cause program termination with a short dump.

If the RAISING statement is specified in a MESSAGE statement within the function module and a return value is assigned to the corresponding exception exc1, exc2, ... sy-subrc is set to this value. If no return value is assigned to the exception after RAISING, the message is influenced, as described above, by the error_message addition.

As of Release 6.10, function modules can pass on class-based exceptions if exception classes are specified in the Function Builder. In this case, the EXCEPTIONS addition must not be specified.

Notes

For the message handling with the predefined exception AB>error_message, it does not make a difference if the message is sent in the currently called function module or in one that is called by this function module. Contrary to the exceptions that are triggered by the statement RAISE, messages sent using the statement MESSAGE are propagated across calling levels.
You can omit the specification of the return value = n after a specified exception when using CALL FUNCTION. If an exception is raised, the value 1 is implicitly assigned to sy-subrc. We recommend to specify the return value explicitly.

Example

Calling the function module GUI_DOWNLOAD for storing the contents of an internal table in a file on the current presentation server. The name of the function module is specified as a literal, which is the most frequent type of specification in static parameter assignment.

DATA: line(80) TYPE c LENGTH 80,
      text_tab LIKE STANDARD TABLE OF line,
      fleng    TYPE i.

...

CALL FUNCTION 'GUI_DOWNLOAD'
  EXPORTING
    filename         = 'c:\temp\text.txt'
    filetype         = 'ASC'
  IMPORTING
    filelength       = fleng
  TABLES
    data_tab         = text_tab
  EXCEPTIONS
    file_write_error = 1
    invalid_type     = 2
    no_authority     = 3
    unknown_error    = 4
    OTHERS           = 10.

CASE sy-subrc.
  WHEN 1.
    ...
  ...
ENDCASE.