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
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.
RAISING can be used to define whether a
propagated from a procedure remains resumable or not. A resumable exception remains resumable only if
RESUMABLE is declared for every parameter interface it passes
when propagated. The addition
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.
- 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.
- 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.