Exception classes are subclasses of the following global classes:
CX_STATIC_CHECK
CX_DYNAMIC_CHECK
CX_NO_CHECK
The common superclass for these classes is CX_ROOT. The assignment to one
of these three superclasses determines the exception category, which itself specifies whether an exception must be declared explicitly in the procedure interface when
propagating from a procedure, and how the declaration is checked:
If exceptions defined using subclasses of CX_STATIC_CHECK are propagated from a procedure, they
must be declared explicitly in the interface of the procedure. The syntax check makes a static check
to determine whether all exceptions raised in the procedure using RAISE EXCEPTION or the addition THROW in a
conditional expression or declared in the
interfaces of called procedures are either handled using CATCH
or declared explicitly in the interface, and produces a warning if this is not the case.
If exceptions defined using subclasses of CX_DYNAMIC_CHECK are propagated from a procedure, they
must be declared explicitly in the interface of the procedure. This is not, however, checked statically
by the syntax check and is instead checked dynamically at the point in time when an exception of this type is propagated from a procedure.
Exceptions defined using subclasses of CX_NO_CHECK may not be declared explicitly in the interface of the procedure. The class CX_NO_CHECK and its subclasses are always declared implicitly and are always propagated. Any
resumability is preserved here.
If an exception not declared in the interface of a procedure is
propagated from the procedure, the interface
is violated and an exception of the predefined class CX_SY_NO_HANDLER is raised in the call point of
the procedure. The exception object of the exception contains a reference to the original exception in the attribute PREVIOUS.
As a rule, exceptions that are raised in a procedure should be handled there or declared in the
interface for the procedure. This declares to the caller which exceptions are to be expected. A syntax
check to verify this is made on exceptions from the category CX_STATIC_CHECK. This category is always
warranted if a procedure is forced to handle an exception or least forward it explicitly. If an exception can be prevented by prior checks, however, exceptions of the category CX_DYNAMIC_CHECK are preferable.
If the program logic can eliminate potential error situations, the corresponding exceptions do not
have to be handled or declared in the interface. This is the case, for example, if there is an explicit
requirement for the denominator not to equal zero prior to a division (a precondition). In this case,
exceptions from the category CX_DYNAMIC_CHECK can and should be used. These exceptions only need to
be handled and declared if their occurrence cannot otherwise be prevented. In well modeled applications,
exceptions are generally prevented by incorporating appropriate conditions in program code and the category CX_DYNAMIC_CHECK should then be the most frequently used exception category.
In exception situations that can occur at any time and that cannot be handled directly, the CX_NO_CHECK
category can be used. Otherwise, all exceptions that can be raised due to resource bottlenecks would
have to be caught or declared. These exceptions would then have to be specified in practically every interface, which would result in more complex programs lacking in clarity.
Most predefined CX_SY_... exceptions for
error situations in the runtime environment are subclasses of CX_DYNAMIC_CHECK. As a result, not every
potential exception of every ABAP statement needs to be handled or declared. Only those that cannot be prevented need to be handled or declared.
The caller of a procedure must anticipate that, in addition to explicitly declared exceptions, the procedure also propagates exceptions from the category CX_NO_CHECK . Some of the predefined
CX_SY_... exceptions for error situations in the runtime environment are subclasses of CX_NO_CHECK.
Interface violations normally only occur for exceptions from the category CX_DYNAMIC_CHECK, since
exceptions from the category CX_STATIC_CHECK are checked first by the syntax check and exceptions from the category CX_NO_CHECK can be raised for any interface.
The resumability
of an exception is not specified as an attribute of the exception class and is instead defined by the
addition RESUMABLE of the statement RAISE EXCEPTION or the addition THROW in a
conditional expression when the exception
is raised. This attribute can be lost for exceptions of type CX_STATIC_CHECK and CX_DYNAMIC_CHECK during
propagation of parameter interfaces of procedures, if the exceptions are not also declared there with RESUMABLE.