What does it do? This statement declares a general instance method meth>. The additions ABSTRACT >> and FINAL>> can be used to make the method of a class abstract or final. The addition DEFAULT>> is used to make an interface method optional. The additions IMPORTING>, EXPORTING>, and CHANGING> define the parameter interface> of the method. After every addition, the corresponding formal parameters are defined by specifying a list parameters>>. The order of the additions is fixed. The remaining additions determine which exceptions are propagated or raised by the method.
Latest notes: Within a method, the predicate expression> IS SUPPLIED>> can be used to check whether an optional formal parameter was assigned an actual parameter when it was called. NON_V5_HINTS ABAP_HINT_END
ABAP Addition p$]>
What does it do? IMPORTING> defines input parameters. When the method is called, an appropriate 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 method. PREFERRED PARAMETER> can be used to flag an input parameter p1 p2 ...> from the list parameters>> after IMPORTING> as a preferred parameter. This specification is only possible if all input parameters and input/output parameters are optional. The parameter specified after PREFERRED PARAMETER> is implicitly set to optional. If the method is called using the syntax meth( a )> (as standalone> or functional> syntax), the actual parameter a> is assigned to the preferred input parameter p >.
Latest notes: Although PREFERRED PARAMETER> makes the parameter p> optional implicitly, this parameter should be made optional explicitly using OPTIONAL> or DEFAULT>, which is required by a syntax check warning. NON_V5_HINTS ABAP_HINT_END
Example ABAP Coding
Declaration of a method with exclusively optional input parameters, of which one is flagged as a preferred parameter. CLASS cls DEFINITION. PUBLIC SECTION. METHODS meth IMPORTING p1 TYPE i DEFAULT 111 p2 TYPE i OPTIONAL p3 TYPE i OPTIONAL PREFERRED PARAMETER p1. ... ENDCLASS.> ABAP_EXAMPLE_END
ABAP Addition
What does it do? EXPORTING> defines output parameters. When the method is called, an appropriate 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 method is completed without errors.
Latest notes: An output parameter that is defined for pass-by-reference behaves like an input/output parameter, which means that it is not initialized when the method is called. For this reason, there should be no read access before the first write access. In addition, be careful when adding content to such parameters as, for example, when inserting lines into internal tables. NON_V5_HINTS ABAP_HINT_END
Example ABAP Coding
The method read_spfli_into_table> of this example has an input and an output parameter, which are typed completely 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.> ABAP_EXAMPLE_END
ABAP Addition
What does it do? CHANGING> defines input/output parameters. When the method is called, an appropriate actual parameter must be specified for each non-optional input/output parameter. The content of the actual parameter is passed to the input/output parameter when it is called and the content of the input/output parameter is passed to the actual parameter after the method has ended.
Example ABAP Coding
Declaration of a method with input and input/output parameters. CLASS html DEFINITION. PUBLIC SECTION. TYPES html_table TYPE ... ... METHODS append_text_to_html IMPORTING text TYPE string CHANGING html TYPE html_table. ... ENDCLASS.> ABAP_EXAMPLE_END
ABAP Addition exc2$|RESUMABLE(exc2) ...>
What does it do? The addition RAISING> is used to declare the class-based exceptions> exc1 exc2 ...> that can be propagated from the method to the caller. For exc1 exc2 ...>, all exception that are classes and that are visible at this point can be specified here. The exception classes must be specified in ascending order with respect to their inheritance hierarchy. Each exception class may only be specified once. The addition RESUMABLE> declares an exception that can be propagated as a resumable exception >. This means:
A resumable exception is propagated as such.
The addition does not have any effect on a non-resumable exception.
If a resumable exception is propagated in RAISING> without the addition RESUMABLE>, it becomes non-resumable. If a superclass is declared as resumable, all of the simultaneously listed subclasses must also be declared as resumable. Exceptions of the categories CX_STATIC_CHECK> and CX_DYNAMIC_CHECK> must be explicitly declared, 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 can also be declared explicitly with or without RESUMABLE>.
Latest notes:
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. For exceptions of the category CX_NO_CHECK> no check is performed.
Exceptions of the category CX_NO_CHECK> can be declared explicitly with or without the addition RESUMABLE>. Implicitly the addition RESUMABLE> is always added. An explicit declaration of an exception of the category CX_NO_CHECK> has no effect but it documents for the user of a method the probability that this exception can be expected. Furthermore, it allows the category of existing exceptions to be changed into CX_NO_CHECK> without leading to a syntax error.
An exception that is raised as resumable in the method with RAISE RESUMABLE EXCEPTION>> should also be declared as resumable in the interface, otherwise the exception would lose this property when the method is exited.
See also Class-Based Exceptions in Procedures>. NON_V5_HINTS
In a method 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 should be handled in a TRY>> control structure. ABAP_HINT_END
Example ABAP Coding
In the class math>, all exceptions that are represented by the class CX_SY_ARITHMETIC_ERROR> and its subclasses are propagated from within the method divide_1_by>. If, for example, the input parameter operand> is filled during the call with the value 0, the exception CX_SY_ZERODIVIDE> is raised, propagated, and can be handled by the caller in a TRY> control structure 8, as shown in the example. ABEXA 00419 ABAP_EXAMPLE_END
ABAP Addition BEGIN_SECTION ID METHODS-EXCEPTIONS
What does it do? The addition EXCEPTIONS> is used to define a list of non-class-based exceptions> exc1 exc2...> that can be raised by the statements RAISE>> or MESSAGE RAISING>> in the method. The names exc1 exc2 ...> for the exceptions that are to be defined are freely definable and specified directly. Exceptions defined in this way are bound to the method, similar to formal parameters, and cannot be propagated. If such an exception is raised in a method and no return code was assigned to it with the addition EXCEPTIONS> in the method call>, a runtime error occurs. The additions RAISING> and EXCEPTIONS> cannot be used simultaneously. In addition, in a method in whose interface non-class-based exceptions are defined, the statement RAISE EXCEPTION>> or the addition THROW>> in a conditional expression> must not be used to raise class-based exceptions.
ABAP_PGL Using Class-Based Exceptions> For new developments, it is recommended that class-based exceptions that are independent of individual methods are used. ABAP_PGL_END
Example ABAP Coding
In the class math>, a non-class-based exception arith_error> is defined for the method divide_1_by> that is raised in the method by the statement RAISE> if an arithmetic error occurs. If, for example, the input parameter operand> is filled with the value 0 during the call, the exception arith_error> is raised in the internal method handling of exception CX_SY_ZERODIVIDE > and handled after the call of the method by evaluating sy-subrc >. The method cannot be called functionally due to the handling of the classic exception. ABEXA 00420 ABAP_EXAMPLE_END END_SECTION ID METHODS-EXCEPTIONS