ARTIClE
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.
You can use declarations with RAISING to define whether a
resumable exception propagated
from a procedure remains resumable or not. A resumable exception remains
resumable only if the RESUMABLE addition is declared for every
parameter interface it is propagated through. The RESUMABLE
addition in RAISING does not make a non-resumable exception
resumable when it is propagated through an interface.
Undeclared 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 defining 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 ). See Class-Based Exceptions
in Event Handlers .
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
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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved