Exception Classes

Superclasses for exception classes

Exception classes are subclasses of the global classes

• CX_STATIC_CHECK

• CX_DYNAMIC_CHECK

• CX_NO_CHECK

The general superclass of these classes is CX_ROOT. Assignment to one of these three superclasses determines whether an exception must be declared directly in the interface of the procedure when propagating from a procedure, and how it is declared:

• If exceptions that are 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 statically checks whether all exceptions triggered in the procedure using RAISE EXCEPTION, or all exceptions declared in the interfaces of called procedures are either handled with CATCH or are declared explicitly in the interface. If they are not, the syntax check issues a warning.

• If exceptions that are 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, however, not checked statically by the syntax check, but is checked dynamically at the moment in which an exception of this type is propagated from the procedure.

• Exceptions that are defined using subclasses of CX_NO_CHECK must not be declared explicitly in the interface of the procedure. The class CX_NO_CHECK and its subclasses are implicitly always declared and are always propagated.

Notes

• In general, exceptions that occur in a procedure should either be handled in the procedure, or declared in the interface of the procedure to inform the user calling the procedure which exceptions can be expected. The corresponding syntax check is justifiable for most application-specific error situations. For this reason, self-defined exception classes should be subclasses of CX_STATIC_CHECK.

• If the program logic can exclude potential error situations, the corresponding exceptions do not have to be handled or declared in the interface. The subclasses of CX_DYNAMIC_CHECK are designed for this purpose. In particular, most predefined exceptions CX_SY_... for error situations in the runtime environment are subclasses of CX_DYNAMIC_CHECK. This means that not every potential exception to every ABAP statement must be handled or declared, but only exceptions whose occurrence cannot be excluded by the program logic.

• The subclasses of CX_NO_CHECK are intended for exception situations such as resource bottlenecks, which can occur at any point and cannot or should not be handled there and then. The consequent tracking of the handling or declaration requirement in this case would mean that these exceptions would have to be specified in almost every interface. When calling a procedure, the user must therefore always expect that the procedure will propagate exceptions of the category CX_NO_CHECK as well as the explicitly declared exceptions. Some of the predefined exceptions CX_SY_... for error situations in the runtime environment are subclasses of CX_ NO_CHECK .

• Violation of an interface normally only occurs for exceptions of the category CX_DYNAMIC_CHECK. This is because exceptions of the category CX_STATIC_CHECK have already been checked by the syntax check, and exceptions of the category CX_NO_CHECK can happen in any interface.

Definition of exception classes

Exception classes can be defined globally in the Class Builder, or locally in a program. The names of global exception classes have the prefix CX_, or YCX_, ZCX_ etc. for exception classes created in customer systems. There is a set of predefined global exception classes, for example, those with the prefix CX_SY_,, which contain exceptions that are triggered by exception situations in the runtime environment.

All exception classes inherit the following instance methods from CX_ROOT:

• GET_TEXT and GET_LONGTEXT return the exception text (short text and long text) as a return value of type string. Before release 6.20, these methods were defined in the class itself. As of release 6.20, they are defined in the interface IF_MESSAGE that is defined in CX_ROOT, and can be addressed using eponymous alias names of the class.

• GET_SOURCE_POSITION returns the program name, the name of a possible include program, and the line number of the trigger position.

All exception classes inherit the following instance attributes from CX_ROOT:

• TEXTID of type SOTR_CONC for a key for the OTR (Online Text Repository) or of type SCX_T100KEY for a key for database table T100, which determines the exception text. This is normally set by the constructor and is evaluated with GET_TEXT

• PREVIOUS of the reference type CX_ROOT, which can contain a reference to a previous exception. This is normally set by the constructor.

The Class Builder generates an instance constructor that cannot be changed for global exception classes, which has optional input parameters for all non-private attributes and sets these to the value of these input parameters. The ID of the required exception text can be passed on to TEXTID. For local exception classes, there are no specific rules for the instance constructor.

Notes

• Instance of exception classes are normally generated by the triggering of exceptions, but can also be instanced using CREATE OBJECT.

• The instance constructor of an exception class should not trigger any exceptions. However, if an exception does occur in the instance constructor after an exception has been triggered during instantiation of the exception class, and the exception cannot be handled there, this or the exception CX_SY_NO_HANDLER - if propagation is unsuccessful - will replace the originally triggered exception.

• Additional methods and attributes can be defined in exception classes, for example, to transport information about an error situation to the handler. The self-defined attributes should be write-protected (READ-ONLY).

Exception Texts

A text that can be assigned parameters by attributes is assigned to each exception, and described the exception situation. If the exception is not treated, this text is displayed in the short dump of the runtime error. When the exception is treated in the program, the text can be retrieved using the method GET_TEXT. One or more texts can be defined for an exception in the Class Builder. There are two options for defining texts:

• If the exception class implements the interface IF_T100_MESSAGE, the short texts from messages in the database table T100 can be used. In the Class Builder, the text is identified by the message class and the message number. If applicable, attributes of the exception class can be assigned to the placeholders "&1" to "&4" or "&" of the message. When an exception occurs, the placeholders are replaced by the content of the attributes. Texts of this type can be sent to the program user while the exception is being treated, using the statement MESSAGE oref.

• If the exception class does not implement the interface IF_T100_MESSAGE, texts stored in the OTR (Online Text Repository) can be used. A text of this type can be defined with any number of placeholders. Each placeholder is represented by the name of an attribute of the exception class, enclosed in "&" characters. When the exception occurs, the placeholders are replaced by the content of the attributes.

For each exception text, the Class Builder creates a static constant in the exception class, which has the name as the exception text. When the exception is triggered, this name can be transferred to the parameter TEXTID of the constructor to determine the exception text. If the parameter is not transferred, a predefined exception text with the same name as the exception class is used.

Notes

• Message texts from the database table T100 should only be used if the text is to be sent to the program user. This can be the case in application programs, but should not occur in system programs. One disadvantage of message short texts is the restriction to 73 characters.

• Texts from the OTR should primarily be used in system programs in which the text is not sent to the program user.