ARTICLE
Exception Categories
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 . Assignment to one of these three superclasses
determines the exception category, which specifies whether an exception
must be explicitly declared 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 explicitly declared 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 explicitly declared in the
interface of the procedure. However, this is not checked statically by
the syntax check; instead, it is checked dynamically at the point in
time when such an exception is propagated from a procedure.
Exceptions that are defined using subclasses of CX_NO_CHECK may
not be explicitly declared in the interface of the procedure. Class
CX_NO_CHECK and its subclasses are always implicitly declared and are
always propagated, and all
resumability is retained.
ABAP_PGL Use a suitable exception
category
Notes
Using Exception Categories
As a rule, exceptions that are raised in a procedure should be handled
there or declared in the interface for the procedure in order to declare
to the caller which exceptions are to be expected. A syntax check to
verify this is run on exceptions from the CX_STATIC_CHECK
category. This category is always warranted if a procedure is to be
forced to handle an exception or to at least explicitly forward it.
However, if an exception can be prevented by prior checks, exceptions of
the CX_DYNAMIC_CHECK category 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, prior to a division, there
is an explicit requirement for the denominator not to equal zero (
precondition ). In this case, exceptions from the CX_DYNAMIC_CHECK
category can and should be used. These exceptions only need to be
handled and declared if their occurrence cannot be otherwise prevented.
In well modeled applications, exceptions are generally prevented by
incorporating appropriate conditions in program code and
CX_DYNAMIC_CHECK category should then be the most frequently used
exception category.
For 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 whose occurrence cannot be prevented need to be handled or
declared.
The caller of a procedure must anticipate that the procedure propagates
exceptions from category CX_NO_CHECK in addition to explicitly
declared exceptions. 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 category
CX_DYNAMIC_CHECK , since exceptions from category
CX_STATIC_CHECK are checked first by the syntax check and exceptions
from category CX_NO_CHECK can be raised for any interface.
Whether an exception is resumable
is not specified as an attribute of the exception class; instead it is
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 .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved