SAP NetWeaver AS ABAP Release 740, ©Copyright 2014 SAP AG. All rights reserved.
Syntax Revisions for Procedures
Cannot Use Untyped Interface Parameters
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
Reason:
Pass by reference is more efficient than passing the value.
Static Check for Interface Parameters
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
Reason:
Runtime errors caused by triggering non-existent exceptions are prevented.
No Definition of Interface Parameters with TABLES
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 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
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)
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, 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
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.