Ansicht
Dokumentation

ABENABAP_OBJECTS_DIFF_PROCEDURES - ABAP OBJECTS DIFF PROCEDURES

ABAP Short Reference   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Syntax Revisions for 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, p must be defined instead of the name in the interface definition VALUE(p). Only the passed value is allowed as the 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 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.

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

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.

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

METHODS meth IMPORTING p1 STRUCTURE struc.

Correct 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, the following statement causes an error message:

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 - and, since Release 7.0, also outside of classes - as an actual parameter for the output parameters of external procedures.

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

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.

BAL Application Log Documentation   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 8913 Date: 20240420 Time: 063003     sap01-206 ( 139 ms )