Skip to content

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 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 addition RAISING then appears as a comment of the statement FUNCTION. 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 exception object contains a reference to the original exception in the attribute PREVIOUS.

The top level of a program into which the exceptions can be propagated consists of processing blocks without local data areas, namely event blocks or dialog modules. Here, all exceptions raised at this level must be handled, since 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 consumer of a class is the first consumer and whether or not this consumer needs to handle exceptions propagated by the static constructor.

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


  • 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.

  • If the exception CX_SY_NO_HANDLER is not handled after the interface is violated, the runtime error is raised by the original exception and the associated short dump describes this exception. This indicates that, primarily, the original exception is to be stopped, handled, or declared by the procedure. The short dump is not intended to specify that the exception CX_SY_NO_HANDLER is handled instead.