CALL - Calling a Method in ABAP Objects

Variants:

Static Variants

1a. CALL METHOD meth    [additions].

1b. [CALL METHOD] meth( [additions] ).

2. [CALL METHOD] meth( ).

3. [CALL METHOD] meth( f ).

4. [CALL METHOD] meth( p1 = f1 ... pn = fn ).


Dynamic Variants

5a. CALL METHOD ref->(f)   [additions].

5b. CALL METHOD class=>(f) [additions].

5c. CALL METHOD (c)=>meth  [additions].

5d. CALL METHOD (c)=>(f)   [additions].

5e. CALL METHOD [ME->](f)  [additions].

Effect

Call a method meth within ABAP objects.

Methods belong to the components of classes. They are accessed either statically using variants 1 through 4 or dynamically using variant 5. Dynamic access to methods is called Dynamic Invoke. Dynamic access via class references allows you to call all methods of an object, irrespective of the type of reference variables.

The interface of a method is completely defined when the method is declared using the METHODS or CLASS-METHODS statement. The additions of the statement CALL METHOD pass actual parameters to this interface, or accept actual parameters from it.

Variant 1a

CALL METHOD meth    [additions].

Variant 1b

[CALL METHOD] meth( [additions] ).

Extras:

1. ... EXPORTING  p1 = f1       ... pn = fn  

2. ... IMPORTING  p1 = f1       ... pn = fn  

3. ... CHANGING   p1 = f1       ... pn = fn  

4. ... RECEIVING  p = f  

5. ... EXCEPTIONS except1 = rc1 ... exceptn = rcn

Effect

Static Method Call

Additions 1 through 5 are used to pass parameters statically. They can also be used for static method calls. If no additions are used, the method meth is called without parameter passing and without exception handling.

For variant 1a, you must specify the statement CALL METHOD. For variant 1b, where the additions are specified in brackets, you can omit the statment CALL METHOD. Variants 2 through 4 are short forms of variant 1b. As before, methods can be called as operands in expressions if they meet certain requirements (see note below).

Addition 1

... EXPORTING p1 = f1       ... pn = fn

Effect

With the EXPORTING addition, the caller must pass type-suitable actual parameters f1 ... fn to all IMPORTING parameters p1 ... pn of a statically called method. These parameters must not be declared as optional.

Example

CLASS C1 DEFINITION.
  PUBLIC SECTION.
    METHODS M1 IMPORTING P1 TYPE I DEFAULT 5
                         P2 TYPE C OPTIONAL
                         P3 TYPE D.
ENDCLASS.

DATA: F TYPE D,
      O1 TYPE REF TO C1.

CREATE OBJECT O1.

CALL METHOD O1->M1 EXPORTING P3 = F.

CLASS C1 IMPLEMENTATION.
  METHOD M1.
    ...
  ENDMETHOD.
ENDCLASS.

The method M1 is called using variant 1a.

Addition 2

... IMPORTING  p1 = f1       ... pn = fn

Effect

Using the optional IMPORTING addition, the caller can copy the EXPORTING parameters p1 ... pn of a method into type-suitable actual parameters f1 ... fn.

Example

CLASS C1 DEFINITION.
  PUBLIC SECTION.
    METHODS M1 EXPORTING P1 TYPE I
                         P2 TYPE C
                         P3 TYPE D.
ENDCLASS.

DATA: F TYPE D,
      O1 TYPE REF TO C1.

CREATE OBJECT O1.

O1->M1( IMPORTING P3 = F ).

CLASS C1 IMPLEMENTATION.
  METHOD M1.
    ...
  ENDMETHOD.
ENDCLASS.

You call the method M1 using variant 1b, while omitting the statement CALL METHOD.

Addition 3

... CHANGING p1 = f1       ... pn = fn

Effect

Using the CHANGING addition, the caller must pass type-suitable actual parameters f1 ... fn to all CHANGING parameters p1 ... pn of a statically called method. These parameters are not declared as optional. As soon as the method is complete, the caller automatically copies the CHANGING parameters into the actual parameters.

Example

CLASS C1 DEFINITION.
  PUBLIC SECTION.
    METHODS M1 CHANGING P1 TYPE I OPTIONAL
                        P2 TYPE C
                        P3 TYPE D DEFAULT SY-DATUM.
ENDCLASS.

DATA: F TYPE C,
      O1 TYPE REF TO C1.

CREATE OBJECT O1.

CALL METHOD O1->M1 CHANGING P2 = F.

CLASS C1 IMPLEMENTATION.
  METHOD M1.
    ...
  ENDMETHOD.
ENDCLASS.

Methode M1 is called using variant 1a.

Addition 4

... RECEIVING p = f

Effect

Using the optional RECEIVING addition, the caller can copy the return value p of a method meth into a type-suitable actual parameter f. The formal parameter is transferred to the actual parameter in the same way as with an assignment (MOVE). You must be able to convert the data type of the formalparameter into the data type of the actual parameter.

Example

CLASS C1 DEFINITION.
  PUBLIC SECTION.
    METHODS M1 RETURNING VALUE(R) TYPE I.
ENDCLASS.

DATA: F TYPE I,
      O1 TYPE REF TO C1.

CREATE OBJECT O1.

O1->M1( RECEIVING R = F ).

CLASS C1 IMPLEMENTATION.
  METHOD M1.
    ...
  ENDMETHOD.
ENDCLASS.

You call method M1 using variant 1b, while omitting the CALL METHOD statement.

Addition 5

... EXCEPTIONS except1 = rc1 ... exceptn = rcn

Effect

Using the optional EXCEPTIONS addition, the caller can handle exceptional situations in a method meth. Exceptions are triggered by the statements ,RAISE except, and MESSAGE RAISING in the method.

The caller handles an exception except by including it in the EXCEPTIONS list and by thus creating a link with a return value rc. If the exception is triggered, the system terminates method processing, returns to the caller, and there assigns the return value rc to the system variable SY-SUBRC.

For output parameters of the method that are defined for value passing (EXPORTING, CHANGING and RETURNING parameters), no values are passed to the actual parameters when an exception occurs. For output parameters defined for reference passing (default setting), the formal parameters and actual parameters have the same value at any one time.

If the caller does not handle an exception triggered by RAISE except, the current program terminates.

If the caller does not handle an exception triggered by MESSAGE RAISING, the specified message is sent, and the system continues processing in accordance with the message type specified.

Notes

1. As with function modules, you can catch the exception OTHERS predefined by the system to handle various user-defined exceptions simultaneously. Specifying the exception ERROR_MESSAGE is, however, not supported for method calls.
   
2. Note that, as of release 6.10, there are class-based exceptions that are caught with TRY ... CATCH ... ENDTRY, and replace the exceptions caught previously using EXCEPTIONS.
   
   
   

Example

CLASS C1 DEFINITION.
  PUBLIC SECTION.
    METHODS M1 EXCEPTIONS EX1
                          EX2.
ENDCLASS.

DATA O1 TYPE REF TO C1.

CREATE OBJECT O1.

O1->M1( EXCEPTIONS EX1 = 10
                   EX2 = 20 ).

CASE SY-SUBRC.
  WHEN 10.
    ...
  WHEN 20.
    ...
ENDCASE.

CLASS C1 IMPLEMENTATION.
  METHOD M1.
    ...
    RAISE EX1.
    ...
    MESSAGE E012(AT) RAISING EX2.
    ...
  ENDMETHOD.
ENDCLASS.

The method M1 is called using variant 1b, while omitting the statement CALL METHOD.

Variant 2

[CALL METHOD] meth( ).

Effect

This short form of variant 1b can be used for static method call if the method meth does not have any, or only optional, input parameters (IMPORTING-or CHANGING parameters). No values are passed. Possible EXPORTING or RETURNING parameters are not accepted after completion of the method.

Example

See example for variant 4.

Variant 3

[CALL METHOD] meth( f ).

Effect

This short form of variant 1b can be used for static method call in the following cases:

• If the method meth has only one single non-optional input parameter (IMPORTING parameter), the system passes the actual parameter f with this variant of the method call to the non-optional input parameter.
  
  
• If the method meth only has optional input parameters, of which one is declared as a preferred parameter using the addition PREFERRED PARAMETER, the actual parameter f can be passed to the preferred parameter using this variant of the method call.
  

However, this method must not have any other interface parameters (EXPORTING, CHANGING, or RETURNING parameters).

Example

See example for variant 4.

Variant 4

[CALL METHOD] meth( p1 = f1 ... pn = fn ).

Effect

This short form of variant 1b can be used for static method call if the method has several input parameters (IMPORTING parameters), whereby the actual parameters f1 ... fn are passed. The method must only have optional CHANGING parameters that are not filled during this call. Possible EXPORTING or RETURNING parameters are not accepted after completion of the method.

Example

class C1 definition.
  public section.
    methods: M0 importing P1 type I optional
                exporting P2 type I
                changing  P3 type I optional,
             M1 importing P1 type I,
             M2 importing P1 type I
                          P2 type I
                returning VALUE(P3) type I.
endclass.

class C1 implementation.
  method M0.
    ...
  endmethod.
  method M1.
    ...
  endmethod.
  method M2.
    ...
  endmethod.
endclass.

data: O1 type ref to C1,
      NUM1 type I,
      NUM2 type I.

start-of-selection.

  create object O1.

  O1->M0( ).

  O1->M1( NUM1 ).

  O1->M2( P1 = NUM1 P2 = NUM2 ).

This example shows short forms of variant 1b.

Note

If a method has an arbitrary number of IMPORTING parameters and a RETURNING parameter, it is a functional method, and then it can be called by CALL METHOD as well as by the following expressions:

• No IMPORTING parameters:
  
  meth( )
  
  
• A non-optional IMPORTING parameter or several optional IMPORTING parameters with a preferred parameter:
  
  meth( f1 )
  
  
• n IMPORTING parameters:
  
  meth( p1 = f1 ... pn = fn )
  
  

This notation style is currently possible

• For the source field of the MOVE statement.
  
• In arithmetic expressions of the COMPUTE statement.
  
• In logical expressions.
  
• In the CASE statement of the CASE control structure.
  
• In the WHEN statement of the CASE control structure.
  
• In the WHERE condition of the LOOP AT statement.
  
  

The functional method is entered instead of an operand. When the statement is executed, the system calls the method and the returned RETURNING parameter is used as an operand.

Variant 5a

CALL METHOD ref->(f)   [additions].

Variant 5b

CALL METHOD class=>(f) [additions].

Variant 5c

CALL METHOD (c)=>meth  [additions].

Variant 5d

CALL METHOD (c)=>(f)   [additions].

Variant 5e

CALL METHOD [ME->](f)  [additions].

Extras:

1. ... PARAMETER-TABLE itab

2. ... EXCEPTION-TABLE itab

Effect

Dynamic Method Call Call

The field f must contain the name of the called method at runtime. The object of an instance method is determined, as in the case of the static method call, via a reference variable. You can specify the class of a static method statically via class or dynamically as the content of the field c. Variant 5e is only possible for methods in your own class.

Additions 1 and 2 are used for dynamic parameter passing. Alternatively, you can also use additions 1 through 5 of the static method call, but in this case the interface of the called method must be statically known. If you use the dynamic method call, the statement CALL METHOD must not be omitted.

Addition 1

... PARAMETER-TABLE itab

Effect

This addition fills the interface of a dynamically called method with actual parameters. The addition PARAMETER-TABLE excludes simultaneous use of the static additions 1 thorugh 4 of variant 1.

The parameter table itab must be a hashed table of the table type ABAP_PARMBIND_TAB or of the line type ABAP_PARMBIND. These types are defined in the ABAP type group in the ABAP dictionary. The table has three columns:

• NAME for the name of the formal parameter
  
• KIND for the type of parameter passing
  
• VALUE of the type REF TO DATA for the value of the actual parameter
  
  

The column NAME is the unique table key. Exactly one line of the internal table must be filled for each non-optional parameter, and one line CAN be filled for each optional parameter.

The type of parameter passing is defined for each formal parameter in the declaration of the called method. The content of the column KIND can, therefore, be initial. If the type of parameter passing is to be checked at runtime, you can assign one of the following constants from the global class CL_ABAP_OBJECTDESCR to the column KIND.

• CL_ABAP_OBJECTDESCR=>EXPORTING for EXPORTING parameters
  
• CL_ABAP_OBJECTDESCR=>IMPORTING für IMPORTING parameters
  
• CL_ABAP_OBJECTDESCR=>CHANGING für CHANGING parameters
  
• CL_ABAP_OBJECTDESCR=>RECEIVING für RECEIVING parameters
  
  
  

The descriptions depend on the caller's view. If the specified and actual parameter types do not match each other, the system generates the exception CX_SY_DYN_CALL_ILLEGAL_TYPE, which can be handled. As before, the entries in the column KIND can serve as an additional key, for example, to edit all the imported values after the method call.

For the value of the actual parameter, the reference VALUE of the table line must point to a data object that contains the required value. For this purpose, you can use the command GET REFERENCEOF f INTO g.

Example

CLASS cl_abap_objectdescr DEFINITION LOAD .

CLASS c1 DEFINITION.
  PUBLIC SECTION.
  METHODS m1 IMPORTING p1 TYPE i.
ENDCLASS.

CLASS c1 IMPLEMENTATION.
  METHOD m1.
    WRITE p1.
  ENDMETHOD.
ENDCLASS.

DATA r TYPE REF TO object.

DATA f(3) TYPE c VALUE 'M1'.

DATA number TYPE i VALUE 5.

DATA: ptab TYPE abap_parmbind_tab,
      ptab_line LIKE LINE OF ptab.

START-OF-SELECTION.

  ptab_line-name = 'P1'.
  ptab_line-kind = CL_ABAP_OBJECTDESCR=>EXPORTING.
  GET REFERENCE OF number INTO  ptab_line-value.
  INSERT ptab_line INTO TABLE ptab.
  IF sy-subrc ne 0.
    EXIT.
  ENDIF.

  CREATE OBJECT r TYPE c1.

  CALL METHOD r->(f) EXPORTING p1 = number.
  CALL METHOD r->(f) PARAMETER-TABLE ptab.

Method m1 of the class c1 is called twice dynamically, whereby the parameter passing takes place once statically and once dynamically. The used reference variable is set for the type with reference to the general class OBJECT.

Addition 2

... EXCEPTION-TABLE itab

Effect

With this addition, the exceptions of a dynamically called method are handled dynamically. The addition EXCEPTION-TABLE excludes simultaneous usage of the static addition 5, variant 1.

The exception table itab must be a hashed table of the table type ABAP_EXCPBIND_TAB or of the line type ABAP_EXCPBIND. These types are defined in the ABAP type group in the ABAP dictionary. The table has two columns:

• NAME for the name of the exception
  
• VALUE of type I for the SY-SUBRC value to be assigned
  
  

The column NAME is the unique table key. For each exception, exactly one line of the internal table can be filled. Here the numeric value is assigned to the component VALUE, which should be in SY-SUBRC after the exception has been triggered.

Example

CLASS cl_abap_objectdescr DEFINITION LOAD.

CLASS c1 DEFINITION.
  PUBLIC SECTION.
  METHODS m1 EXCEPTIONS exc.
ENDCLASS.

CLASS c1 IMPLEMENTATION.
  METHOD m1.
    RAISE exc.
  ENDMETHOD.
ENDCLASS.

DATA r TYPE REF TO object.

DATA f(3) TYPE c VALUE 'M1'.

DATA: etab TYPE abap_excpbind_tab,
      etab_line LIKE LINE OF etab.

START-OF-SELECTION.

  etab_line-name = 'EXC'.
  etab_line-value = 4.
  INSERT etab_line INTO TABLE etab.
  IF sy-subrc ne 0.
    EXIT.
  ENDIF.

  CREATE OBJECT r TYPE c1.

  CALL METHOD r->(f) EXCEPTIONS exc = 4.
  WRITE sy-subrc.
  CALL METHOD r->(f) EXCEPTION-TABLE etab.
  WRITE sy-subrc.

The method m1 of the class c1 is called twice dynamically, whereby the exception handling takes place once statically and once dynamically. The user reference variable is set to the type with reference to the general class OBJECT.

Exceptions

Catchable Exceptions

CX_SY_DYN_CALL_EXCP_NOT_FOUND

• Cause: Exception does not exist
  Runtime Error: DYN_CALL_METH_EXCP_NOT_FOUND (catchable)
  

CX_SY_DYN_CALL_ILLEGAL_CLASS

• Cause: The specified class is abstract.
  Runtime Error: DYN_CALL_METH_CLASS_ABSTRACT (catchable)
  
• Cause: The specified class does not exist
  Runtime Error: DYN_CALL_METH_CLASS_NOT_FOUND (catchable)
  

CX_SY_DYN_CALL_ILLEGAL_METHOD

• Cause: The method cannot be accessed.
  Runtime Error: CALL_METHOD_NOT_ACCESSIBLE
  
• Cause: The called method is not yet implemented.
  Runtime Error: CALL_METHOD_NOT_IMPLEMENTED
  
• Cause: Call of static constructor
  Runtime Error: DYN_CALL_METH_CLASSCONSTRUCTOR (catchable)
  
• Cause: Call of instance constructor
  Runtime Error: DYN_CALL_METH_CONSTRUCTOR (catchable)
  
• Cause: Method does not exist
  Runtime Error: DYN_CALL_METH_NOT_FOUND (catchable)
  
• Cause: Method is not static
  Runtime Error: DYN_CALL_METH_NO_CLASS_METHOD (catchable)
  
• Cause: Call of a method that is not visible
  Runtime Error: DYN_CALL_METH_PRIVATE (catchable)
  
• Cause: Call of a method that is not visible
  Runtime Error: DYN_CALL_METH_PROTECTED (catchable)
  

CX_SY_DYN_CALL_ILLEGAL_TYPE

• Cause: Type conflict calling the method.
  Runtime Error: CALL_METHOD_CONFLICT_GEN_TYPE
  
• Cause: Type conflict calling the method.
  Runtime Error: CALL_METHOD_CONFLICT_TAB_TYPE
  
• Cause: Type conflict calling the method.
  Runtime Error: CALL_METHOD_CONFLICT_TYPE
  
• Cause: Incorrect type of a parameter
  Runtime Error: DYN_CALL_METH_PARAM_KIND (catchable)
  
• Cause: Actual parameter cannot be filled
  Runtime Error: DYN_CALL_METH_PARAM_LITL_MOVE (catchable)
  
• Cause: Incorrect table type of a parameter
  Runtime Error: DYN_CALL_METH_PARAM_TAB_TYPE (catchable)
  
• Cause: Incorrect type of a parameter
  Runtime Error: DYN_CALL_METH_PARAM_TYPE (catchable)
  

CX_SY_DYN_CALL_PARAM_MISSING

• Cause: Missing actual parameter
  Runtime Error: DYN_CALL_METH_PARAM_MISSING (catchable)
  
• Cause: Parameter reference is empty
  Runtime Error: DYN_CALL_METH_PARREF_INITIAL (catchable)
  

CX_SY_DYN_CALL_PARAM_NOT_FOUND

• Cause: Incorrect name of a parameter
  Runtime Error: DYN_CALL_METH_PARAM_NOT_FOUND (catchable)
  

CX_SY_REF_IS_INITIAL

• Cause: Reference variable is empty
  Runtime Error: DYN_CALL_METH_REF_IS_INITIAL (catchable)
  
  

Non-Catchable Exceptions

• Cause: Non-allowed parameter during dynamic method call.
  Relevant for instance constructors during dynamic instantiation.
  Runtime Error: CALL_METHOD_PARMS_ILLEGAL
  
  
  

Related

Additional help

Declare and Call Methods