Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Program Flow →  Exception Handling →  Class-Based Exceptions →  Exception Classes 

Exception Categories

Exception classes are subclasses of the following global classes:


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 with RAISE EXCEPTION or declared in the interfaces of called procedures are either handled with CATCH or explicitly declared in the interface, and issues 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.

Other versions: 7.31 | 7.40 | 7.54

Programming Guideline

Use a suitable exception category


  • 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 something that is specified as an attribute of the exception class; it is defined by the RESUMABLE addition of the RAISE EXCEPTION statement 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.