ABAP Keyword Documentation →  ABAP - Reference →  Program Flow Logic →  Exception Handling →  Class-Based Exceptions →  System Response After a Class-Based Exception 

Class-Based Exceptions in Procedures

If a class-based exception is not handled in a procedure, the system attempts to propagate it to the caller of the procedure. The exceptions that can be propagated from a procedure must be declared in its interface. The caller then knows which exceptions to expect from the procedure. Class-based exceptions are divided into three categories, which determine whether the declaration must be explicit and how it is checked.

In methods of local classes and subroutines, the addition RAISING of the statements METHODS and FORM is used for the declaration. In function modules and methods of global classes, class-based exceptions are declared in the interface by selecting the Exception Class checkbox on the relevant tab page in Class Builder or Function Builder. The declaration of an exception class in an interface is polymorphous. It declares all subclasses simultaneously.

Declarations using RAISING can be used to define whether a resumable exception propagated from a procedure remains resumable or not. A resumable exception remains resumable only if the addition RESUMABLE is declared for every parameter interface it passes when propagated. The addition RESUMABLE in RAISING does not make a non-resumable exception resumable when it is propagated through an interface.

Undeclared exceptions cannot leave a procedure and violate the interface if they are not handled within the procedure. A violation of the interface raises an exception of the predefined class CX_SY_NO_HANDLER, whose attribute PREVIOUS contains a reference to the original exception.

The top level of a program into which the exceptions can be propagated are processing blocks without local data area, that is event blocks or dialog modules. Here, all exceptions raised there must be handled; otherwise a runtime error occurs.

When exceptions are propagated from procedures, the following restrictions apply:

• Exceptions cannot be declared in the definition of a static constructor. This means that exceptions cannot leave the static constructor. It is not normally possible to tell whether the user of a class is the first user and whether or not this user needs to handle exceptions propagated by the static constructor.

• Exceptions cannot be declared in the definition of an event handler. This means that no exceptions can be propagated from an event handler (except those of category CX_NO_CHECK). See Class-Based Exceptions in Event Handlers.

Programs called using SUBMIT ... AND RETURN or CALL TRANSACTION cannot propagate exceptions to the caller, since exception objects are bound to the internal session of a program.

Other versions: 7.31 | 7.40 | 7.54

Note

When an exception of type CX_SY_NO_HANDLER is raised, this indicates a programming error within a procedure, where the programmer forgot to prevent an exception of category CX_DYNAMIC_CHECK or CX_STATIC_CHECK, handle it locally, or declare it. When exceptions of type CX_SY_NO_HANDLER are handled, it is therefore best not to try to handle the original exception and inform the person responsible for the program instead. In the case of exceptions of type CX_STATIC_CHECK, the syntax check also reports this.