Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Obsolete Language Elements →  Obsolete modularization →  Subroutines 

FORM

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Obsolete Syntax

FORM subr [TABLES table_parameters]
          [USING parameters]
          [CHANGING parameters]
          [RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...].
  ...
ENDFORM.

Extras

1. ... TABLES table_parameters

2. ... USING parameters

3. ... CHANGING parameters

4. ... RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...

Effect

The FORM statement 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 and the global data types and data objects of the frame program can be accessed.

Subroutines are called using the statement PERFORM.


Note

Subroutines are obsolete. In new programs, methods must be used instead.

Addition 1

... TABLES table_parameters

Effect

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, then an empty local header line is generated in the subroutine. If an internal table with header line is used as the actual parameter, then 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.


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 in the subroutine using the addition LIKE LINE OF itab of statement DATA.
  • If TABLES is specified after USING or CHANGING, a formal parameter called "TABLES" is created.

Addition 2

... USING parameters

Addition 3

... CHANGING parameters

Effect

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
    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 reference for CHANGING parameters
    The formal parameters p1 p2 ... are handled exactly like those parameters defined for pass by reference using USING.
  • Pass by value for USING parameters
    For each formal parameter p1 p2 ..., a local data object with the same data type as the corresponding 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 corresponding 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.


Notes

  • Formal parameters defined for pass by reference with USING should not be changed in the subroutine. In this case, CHANGING can be used instead. Write accesses cause warnings during the syntax check.
  • The addition CHANGING should be used for the formal parameter whose value is changed in the subroutine.
  • The order of USING and CHANGING is not arbitrary. Specifying USING after CHANGING creates a formal parameter called "USING".


Example

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 row type of the internal table.

FORM fill_table USING    wa   TYPE any 
               CHANGING ptab TYPE INDEX TABLE. 
  APPEND wa TO ptab. 
ENDFORM.

Addition 4

... RAISING exc1|RESUMABLE(exc1) exc2|RESUMABLE(exc2) ...

Effect

The addition RAISING can be used to pass class-based exceptions exc1 exc2 ..., which are triggered in or propagated to the subroutine by the ABAP runtime environment 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.

For exc1 exc2 ..., all exception classes that are visible at this point that are subclasses of CX_STATIC_CHECK CX_DYNAMIC_CHECK 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.

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 that must be handled by the caller CX_SY_NO_HANDLER.

The RESUMABLE addition declares an exception that can be propagated as a resumable exception. This means:

  • A resumable exception is therefore propagated as such
  • The addition does not have any effect on a non-resumable exception.
  • If a resumable exception is propagated with RAISING without the addition RESUMABLE, it thus becomes non-resumable.

If a superclass is declared as resumable, any subclasses must also be declared as resumable.


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.
  • In a subroutine that propagates class-based exceptions with the RAISING addition, the CATCH SYSTEM-EXCEPTIONS statement cannot be used. Instead, the corresponding handleable exceptions must be caught in a TRY block.
  • 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.

Continue

FORM - parameters

FORM - STRUCTURE

FORM - table_parameters