What does it do? The statement FORM defines a subroutine subr and its interface. Naming conventions apply to the subr name. The functions of the subroutine subr are implemented between the statements FORM and ENDFORM. The additions define the formal parameters of the subroutine and declare the propagation of the class-based exceptions to the caller. Local data types and data objects can be declared within the subroutine. Furthermore, the formal parameters of the subroutine as well as the global data types and data objects of the current compilation unit can be accessed. Subroutines are called using the statement PERFORM .
Latest notes: Subroutines are obsolete. In new programs, methods should be created instead. NON_V5_HINTS ABAP_HINT_END • TABLES FORM (obsolete)
ABAP Addition
What does it do? TABLES is used to declare table parameters table_parameters. Table parameters are obsolete formal parameters that are typed as internal standard tables with header lines. The addition TABLES can be specified only before USING or CHANGING. If an internal table without header line or a table body is passed as an actual parameter to this type of formal parameter, an empty local header line is generated in the subroutine. If an internal table with header line is used as the actual parameter, both the table body and the header line are passed to the subroutine. Pass by value is not possible in formal parameters defined using TABLES.
Latest notes:
Formal parameters defined using TABLES can be replaced by formal parameters defined using USING or CHANGING. A local work area can also be created for the internal table in the subroutine using the addition LIKE LINE OF itab of the statement DATA.
If TABLES is specified after USING or CHANGING, a formal parameter called TABLES is created. NON_V5_HINTS ABAP_HINT_END • USING FORM (obsolete) • CHANGING FORM (obsolete)
ABAP Addition
ABAP Addition
What does it do? These additions define formal parameters parameters. Formal parameters can be used in the subroutine as data objects in all operand positions that match their typing and their modifiability defined by USING or CHANGING. When the formal parameters parameter are defined, either pass by reference or pass by value can be defined. The effect of this definition for formal parameters defined with USING and CHANGING is as follows:
Pass by reference for USING parameters The formal parameters p1 p2 ... are handled exactly like those parameters defined for pass by reference using CHANGING.
Pass by reference for CHANGING parameters For the formal parameters p1 p2 ..., no local data object is created in the subroutine. Instead, when it is called, a reference is passed to the specified actual parameter. A change to the formal parameter in the subroutine also changes the value of the actual parameter.
Pass by value for USING parameters For each formal parameter p1 p2 ..., a local data object with the same data type as the associated actual parameter is created in the subroutine and filled with its values. A change to the formal parameter in the subroutine does not change the value of the actual parameter. The actual parameter also retains its original value even after the subroutine has ended.
Pass by value for CHANGING parameters For each formal parameter p1 p2 ..., a local data object with the same data type as the associated actual parameter is created in the subroutine and filled with its values. A change to the formal parameter in the subroutine does not directly change the value of the actual parameter. If the subroutine is ended using ENDFORM, RETURN , CHECK, or EXIT however, the content of the formal parameter is assigned to the actual parameter. If the subroutine is ended by a message or an exception, the actual parameter remains unchanged.
Latest notes:
Formal parameters defined for pass by reference with USING should not be changed in subroutines. In this case, CHANGING can be used instead. Write access to USING parameters produces syntax check warnings if CHANGING parameters are specified at the same time.
The addition CHANGING should be used for precisely those formal parameters whose value is changed in the subroutine.
The order of USING and CHANGING is not arbitrary. Specifying USING after CHANGING creates a formal parameter named using.
Since from the caller's point of view there is no syntactical difference between passing an actual parameter to a USING parameter defined for pass by value or to a USING parameter defined for pass by reference, the value returned by the subroutine should not depend on the kind of parameter passing. NON_V5_HINTS ABAP_HINT_END
Example ABAP Coding
In a subroutine, the formal parameter ptab can be used in an operand position that expects an index table, since it is typed accordingly. The formal parameter wa is completely generic and the system waits until runtime to check whether it is suitable for the line type of the internal table. ABEXA 00280 ABAP_EXAMPLE_END • RESUMABLE FORM (obsolete) • RAISING FORM (obsolete)
ABAP Addition exc2$|RESUMABLE(exc2) ...
What does it do? The addition RAISING can be used to declare class-based exceptions exc1 exc2 ..., which are raised in or propagated to the subroutine by the ABAP runtime framework or using the statement RAISE EXCEPTION or the addition THROW in a conditional expression, but are not handled in a TRY block. Subclasses of CX_STATIC_CHECK and CX_DYNAMIC_CHECK can be declared explicitly. Subclasses of CX_NO_CHECK are always declared implicitly with the addition RESUMABLE but can also be declared explicitly. For exc1 exc2 ..., all exception classes that are visible at this point can be specified. The exception classes must be specified in ascending order with respect to their inheritance hierarchy. Each exception class may only be specified once. If an exception for this superclass is raised that cannot be handled and cannot be passed on, this produces either a syntax error or an exception CX_SY_NO_HANDLER that must be handled by the caller. The addition RESUMABLE declares an exception that can be propagated as a resumable exception . This means:
A resumable exception is therefore propagated as such
The addition has no effect on a non-resumable exception.
If a resumable exception is propagated in RAISING and the addition RESUMABLE is not specified, it thus becomes non-resumable. If a superclass is declared as resumable, any subclasses must also be declared as resumable.
Latest notes:
Exceptions that are based on the subclasses of CX_STATIC_CHECK and CX_DYNAMIC_CHECK must be handled either in the subroutine or declared explicitly using the RAISING addition. For CX_STATIC_CHECK, this is checked during the syntax check; for 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. The addition RESUMABLE is always added implicitly. An explicit declaration of an exception of the category CX_NO_CHECK has no effect but documents for the user of a subroutine, that this exception is to be expected. Furthermore, it allows the category of existing exceptions to be changed to CX_NO_CHECK without producing a syntax error.
An exception that is raised as a resumable exception in the subroutine using RAISE RESUMABLE EXCEPTION should also be declared as resumable in the interface, since the exception would otherwise lose this property when the method is exited.
See also Class-Based Exceptions in Procedures. NON_V5_HINTS
In a subroutine, 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
