Class-Based Exceptions in Procedures

If a class-based exception is not handles in a procedure, the system tries to propagate it to procedure caller. In a procedure's interface, you must declare the exceptions that can be propagated from that procedure. The caller therefore 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 to check it.

For methods of local classes and subroutines, you use addition RAISING of the statements METHODS and FORM for the declaration. For function modules and methods of global classes, you declare class-based exceptions in the interface by selecting the Exception Class checkbox on the respective tab page of the

Class or Function Builders. The declaration of an exception class in an interface is polymorphous. It simultaneously declares all subclasses.

Not declared exceptions cannot leave a procedure, but violate the interface if they are not handled within the procedure. A violation of the interface triggers an exception of 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 that occur there must be handled, or else a runtime error will occur.

When propagating exceptions from procedures, the following restrictions apply:

• When defining a static constructor, you cannot declare any exceptions. 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.

• When defnining an event handler, you cannot declare any exceptions. This means that no exceptions can be propagated from an event handler (except those of category CX_NO_CHECK). Event handlers and exceptions are completely decoupled. The triggerer of an event does not know the handlers and therefore cannot handle their exceptions.

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

Note

Whene an exception of type CX_SY_NO_HANDLER occurs, this usually indicates a programming error within a procedure, where the programmer forgot to prevent, to locally handle or to declare an exception of category CX_DYNAMIC_CHECK or CX_STATIC_CHECK. When handling exceptions of type CX_SY_NO_HANDLER, you should therefore not try to handle the original exception, but inform the person responsible for the program. As far as exceptions of type CX_STATIC_CHECK are concerned, the syntax check will also report this.