In ABAP, each class-based exception belongs to one of the three different exception categories, each of which define whether the exceptions need to be declared in procedure interfaces. All exception classes are subclasses of the following abstract global classes, which themselves inherit from CX_ROOT. Then, by creating and raising class-based exceptions, you should always use an exception category suitable for the current error situation:
CX_STATIC_CHECK for the static protection of the exception handler
CX_DYNAMIC_CHECK for error situations that can be prevented by preconditions
CX_NO_CHECK for situations that cannot be handled immediately
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.
In earlier releases, when exceptions defined using subclasses of CX_STATIC_CHECK or CX_DYNAMIC_CHECK are propagated from a procedure, they must be explicitly declared in the interface of the procedure while it was not the case for exceptions that are defined using subclasses of CX_NO_CHECK. Exceptions that are defined using subclasses of CX_NO_CHECK can always be propagated, whereby a possible resumability is preserved. It is not necessary to declare exceptions defined using subclasses of CX_NO_CHECK in the interface of a procedure. They are declared implicitly, but now, it is also possible to declare subclasses of CX_NO_CHECK explicitly in the interface of a procedure.
Declaration of CX_NO_CHECK exceptions
As said, each exception categories are designed for different error situations. 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 must be declared in almost every interface, which would result in more complex programs lacking in clarity.
Up to release 7.55, exceptions that are defined using sub classes of CX_NO_CHECK may not be explicitly declared in the interface of the procedure. Class CX_NO_CHECK and its subclasses are always declared implicitly in interfaces of procedures and can always be propagated. This means, by calling a procedure, an exceptions of the category CX_NO_CHECK as well as the explicitly declared exceptions would be propagated.
From now on, it is also possible to declare exceptions of category CX_NO_CHECK with RAISING in procedure interfaces, for example for methods. This allows it to document the possible occurrence of such exceptions and to change the category of existing exceptions into CX_NO_CHECK without causing errors in interface definitions.
If an exception of category CX_STATIC_CHECK or CX_DYNAMIC_CHECK is propagated from the procedure but not declared in the interface of the procedure, the interface is violated and an exception of the predefined class CX_SY_NO_HANDLER is raised at the call point of the procedure. The exception object of the exception contains a reference to the original exception in the attribute PREVIOUS. An exception of category CX_NO_CHECK can be propagated independently of its explicit declaration in the procedure interface.
Let us implement a test class, ZCL_RUNTIME_EXCEPTION, for the following class which is inherited from Class CX_NO_CHECK. As you see, CX_NO_CHECK based exception is raised and caught successfully.
CLASS zcx_no_check DEFINITION INHERITING FROM cx_no_check.
CLASS ZCL_RUNTIME_EXCEPTION DEFINITION FOR TESTING DURATION SHORT RISK LEVEL HARMLESS.
raising_cx_no_check RAISING zcx_no_check,
exceptions_test FOR TESTING.