Procedures

Cannot Use Untyped Interface Parameters

In ABAP Objects, the TYPE addition is required for the interface parameters of procedures. The only procedures allowed in ABAP Objects are methods.

In ABAP Objects, the following statement causes an error message:

METHODS meth IMPORTING p1
             EXPORTING p2.

Correct syntax:

METHODS meth IMPORTING p1 TYPE ANY
             EXPORTING p2 TYPE ANY.

Cause:

In ABAP Objects, the interface parameters of parameters must always be explicitly typed. Use the TYPE ANY addition if you want an interface parameter to be completely generic.

Pass by Reference is Standard for Methods

In contrast to function modules, pass by reference is the standard for interface parameters of methods. To pass a parameter as value, pmust be defined instead of the name in the interface definition VALUE(p). Only the passed value is allowed as return value (RETURNING parameter).

Reason:

Pass by reference is more efficient than passing the value.

Static Check for Interface Parameters

Unlike function modules, when a method is called the system performs a static syntax check on declared interface parameters. This applies to both local and global classes. It checks that the declared formal parameters are valid, the actual parameters have the correct type, and that all the obligatory input parameters have had values passed to them.

Cause:

Reduces runtime errors when the program runs. The extended program check performed on interfaces s not always sufficient.

Exceptions must be defined in the triggering class

In contrast to function modules, only those exceptions can be triggered in a method that have been defined for this method. The static syntax check checks whether the exception exists (when an exception is triggered by the statement RAISE and when it is handled using the exception EXCEPTIONS of the statement CALL METHOD).A non-existent exception raised in a function module merely causes a syntax warning message, and handling of a non-existent exception in the statement CALL FUNCTION is not checked at all. Therefore undefined exceptions can be raised and handled in function modules.

Reason:

Runtime errors caused by triggering non-existent exceptions are prevented.

No Definition of Interface Parameters with TABLES

In ABAP objects the construct TABLES for defining formal parameters is not allowed in procedures. The only procedures allowed in ABAP objects are methods.

Error message in ABAP objects for:

METHODS meth TABLES p1.

Correct syntax:

METHODS meth CHANGING p1 LIKE itab.

Reason:

Internal tables are passed like all data objects as IMPORTING, EXPORTING, CHANGING or RETURNING parameters.

No Obsolete Casting for Interface Parameters

In ABAP objects the construct STRUCTURE for defining the types of formal parameters in procedures is not allowed. The only procedures allowed in ABAP objects are methods.

Error message in ABAP objects for:

METHODS meth IMPORTING p1 STRUCTURE struc.

Correkt syntax:

METHODS meth IMPORTING p1 TYPE struc.

or

METHODS meth IMPORTING p1 TYPE ANY.

METHOD meth.
  FIELD-SYMBOLS <fs> TYPE struc.
  ASSIGN p1 TO <fs> CASTING.
  ...
ENDMETHOD.

Reason:

Formal parameters whose type is defined with STRUCTURE are a mixture of parameters with types and parameters for which there is a casting for data types defined in the ABAP Dictionary or locally in the program. The types of the field symbols are defined with the TYPE addition. Local field symbols and the ASSIGN ... CASTING statement can be used for the casting.

Cannot Use the LOCAL Statement

The LOCAL statement is not allowed in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

LOCAL f.

Cause:

The LOCAL statement protects global data objects from being changed in subroutines. This is pointless when you use methods, since methods are designed to work with the attributes of classes. You can create local data objects in methods and subroutines for internal purposes.

Cannot Use PERFORM form(prog)

You cannot declare an external subroutine using the syntax form(prog) in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

PERFORM form(prog) ...

Correct syntax:

PERFORM form IN PROGRAM prog ...

Cause:

The PERFORM form IN PROGRAM prog has replaced the PERFORM form(prog) statement. The name declaration form IN PROGRAM prog (unlike form(prog)) allows you to declare dynamic program names using the form IN PROGRAM (name) variant. Conversely, the static form, form(prog)does not comply with standard ABAP semantics, in which the dynamic variant is differentiated from the static variant using parentheses.

Passing SY-REPID not allowed

In ABAP Objects, you cannot pass the system field SY-REPID as an actual parameter to an external procedure.

In ABAP Objects, an error message occurs on:

CALL FUNCTION func EXPORTING p = sy-repid.

Correct syntax:

DATA repname TYPE sy-repid.

repname = sy-repid.
CALL FUNCTION func EXPORTING p = repname.

Reason:

When the parameters are passed to the formal parameters, SY-REPID already contains the name of the main program of the procedure you have called, even though you intended to pass the name of the calling program.

No transfer of SY-SUBRC

The system field SY-SUBRC must not be used in ABAP Objects as an actual parameter for the output parameters of external procedures.

Error message in ABAP Objects in the following case:

CALL FUNCTION func IMPORTING p = sy-subrc.

Correct syntax:

DATA subrc TYPE sy-subrc.

CALL FUNCTION func IMPORTING p = subrc.

Reason:

After parameter transfer, SY-SUBRC is set by the call statement. This overwrites the transferred value. With a few exceptions, system fields should never be overwritten explicitly in a program.