METHODS - IMPORTING, EXPORTING, CHANGING, RAISING

Syntax

METHODS meth [ABSTRACT|FINAL]
  [IMPORTING parameters [PREFERRED PARAMETER p]]
  [EXPORTING parameters]
  [CHANGING parameters]
  [{RAISING|EXCEPTIONS} exc1 exc2 ...].

Extras:

1. ... IMPORTING parameters [PREFERRED PARAMETER p]

2. ... EXPORTING parameters

3. ... CHANGING parameters

4. ... RAISING exc1 exc2 ...

5. ... EXCEPTIONS exc1 exc2 ...

6. ... ABSTRACT ...

7. ... FINAL ...

Effect

This statement declares a general instance method meth. Use additions ABSTRACT and FINAL to make the method abstract or final.

The additions IMPORTING, EXPORTING and CHANGING define the parameter interface of the method. After every addition, the corresponding formal parameters are defined by a specification of the list parameters.

The other additions determine which exceptions the method can propagate or trigger and determine whether the method is abstract or final.

Note

Within a method, you can use the logical expression IS SUPPLIED to check whether an actual parameter was assigned to an optional formal parameter at the call.

Addition 1

... IMPORTING parameters [PREFERRED PARAMETER p]

Effect

IMPORTING defines input parameters. When calling the method, you need not specify an appropriate actual parameter for every non-optional input parameter. During the call, the content of the actual parameter is passed to the input parameter. The content of the input parameter - for which the reference transfer is defined - cannot be changed in the method.

Use PREFERRED PARAMETER to identify an input parameter p1 p2 ... of list parameters after IMPORTING as a preferred parameter. This specification makes sense only if all input parameters are optional. When calling the method with the syntax

[CALL METHOD] meth( a ).

the actual parameter a is assigned to the preferred parameter if you have appropriate use of a functional method at an operand position.

Addition 2

... EXPORTING parameters

Effect

EXPORTING defines output parameters. When calling the method, you can specify an appropriate actual parameter for every output parameter. The content of the output parameter - which is defined for value transfer - is passed to the actual parameter at the call after the method has been completed successfully.

Note

An output parameter that is defined for the reference transfer is not initialized when the method is called. Therefore, no read access to it should take place before the first write access.

Addition 3

... CHANGING parameters

Effect

CHANGING defines input/output parameters. When calling the method, you must specify an appropriate actual parameter for every non-optional input/output parameter. The content of the actual parameter is passed to the input/output parameter at the call, and after the method has been completed, the content of the input/output parameter is passed to the actual parameter.

Example

The method read_spfli_into_table of this example has an input and an output parameter, which are typed fully by reference to the ABAP Dictionary.

CLASS flights DEFINITION.
  PUBLIC SECTION.
    METHODS read_spfli_into_table
       IMPORTING VALUE(id)  TYPE spfli-carrid
       EXPORTING flight_tab TYPE spfli_tab.
       ...
ENDCLASS.

Addition 4

... RAISING exc1 exc2 ...

Effect

Use addition RAISING to declare the class-based exceptions exc1 exc2 ... that can be propagated from the method to the caller.

For exc1 exc2 ..., you can specify all exception classes that are visible at this position and are subclasses of CX_STATIC_CHECK or CX_DYNAMIC_CHECK. You must specify the exception classes in ascending order corresponding to their inheritance hierarchy.

Exceptions of the categories CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be declared explicitly, otherwise a propagation results in a violation of the interface. An interface violation results in a treatable exception CX_SY_NO_HANDLER. Exceptions of category CX_NO_CHECK are always implicitly declared.

Notes

Example

In class math, you can propagate all exceptions represented by class CX_SY_ARITHMETIC_ERROR and its subclasses from within method divide_1_by. If, for example, the input parameter operand is filled at the call with the value 0, then the exception CX_SY_ZERODIVIDE is triggered, propagated, and can, as shown in the example, be handled by the caller in a TRY control structure.

CLASS math DEFINITION.
  PUBLIC SECTION.
    METHODS divide_1_by
       IMPORTING operand TYPE I
       EXPORTING result  TYPE f
       RAISING   cx_sy_arithmetic_error.
ENDCLASS.

CLASS math IMPLEMENTATION.
  METHOD divide_1_by.
    result = 1 / operand.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

DATA oref TYPE REF TO math.
DATA exc  TYPE REF TO cx_sy_arithmetic_error.
DATA res  TYPE f.
DATA text TYPE string.

CREATE OBJECT oref.
TRY.
    oref->divide_1_by( EXPORTING operand = 4
                       IMPORTING result = res ).
    text = res.
  CATCH cx_sy_arithmetic_error INTO exc.
    text = exc->get_text( ).
ENDTRY.
MESSAGE text TYPE 'I'.

Addition 5

... EXCEPTIONS exc1 exc2 ...

Effect

Use addition EXCEPTIONS to define a list of non-class-based exceptions exc1 exc2..., which can be triggered with the statements RAISE or MESSAGE RAISING in the method. You specify identifiers exc1 exc2 ... for the exceptions to be defined at will and directly. Exceptions defined in this way are bound to the method - similar to formal parameters - and cannot be propagated.

If such an exception is triggered in a method and no return value has been assigned to it in the addition EXCEPTIONS of the CALL METHOD statement in the method call, then a runtime error occurs.

Note

The additions RAISING and EXCEPTIONS cannot be used simultaneously. For new developments starting at release 6.10, we recommend to use class-based exceptions, which are independent of the respective method.

Example

In the class math, for method divide_1_by an exception arith_error is defined, which is triggered in the method with the RAISE statement if an arithmetic error occurs. If, for example, the input parameter operand is filled with value 0 at the call, the exception arith_error is triggered in the method-internal handling of exception CX_SY_ZERODIVIDE and handled after the call of the method by evaluating sy-subrc.

CLASS math DEFINITION.
  PUBLIC SECTION.
    METHODS divide_1_by
       IMPORTING  operand TYPE I
       EXPORTING  result  TYPE f
       EXCEPTIONS arith_error.
ENDCLASS.

CLASS math IMPLEMENTATION.
  METHOD divide_1_by.
    TRY.
        result = 1 / operand.
      CATCH cx_sy_arithmetic_error.
        RAISE arith_error.
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

DATA res  TYPE f.
DATA oref TYPE REF TO math.

CREATE OBJECT oref.
oref->divide_1_by( EXPORTING  operand = 4
                   IMPORTING  result  = res
                   EXCEPTIONS arith_error = 4 ).

IF sy-subrc = 0.
  WRITE res.
ELSE.
  WRITE 'Arithmetic error!'.
ENDIF.

Addition 6

... ABSTRACT ...

Effect

Use addition ABSTRACT to define an abstract method meth. Addition ABSTRACT is allowed only in abstract classes, not in interfaces. An abstract method is not implemented in the implementation section of its class. To implement an abstract method, you must redefine it in a non-abstract subclass using addition REDEFINITION.

Notes

Addition 7

... FINAL ...

Effect

Addition FINAL is allowed only in classes, not in interfaces. Use addition FINAL to define a final method meth. A final method cannot be redefined in a subclass. In final classes, all methods are automatically final; the addition FINAL is not allowed.