The most important feature of a caught exception is the fact that it has occurred and that it is handled in the program. It is left to the handler to decide how the exception situation is dealt with. It is not up to the exception itself to interact with the program user.

Nevertheless, an explanatory text is assigned to each exception. This text describes the exception situation more precisely and is output as an error message if the exception is not handled. It should, however, only be used sparingly during exception handling for communication with the user. The exception text describes an error situation from a mostly technical view. If an exception is described to a user, it should be described from the user's perspective.

Exception texts can contain parameters that enable an error situation to be described more precisely. Elementary attributes of the exception class whose content can be interpreted as text are used here. You can convert attributes into parameters of exception texts by displaying their name using the character '&' in the exception text. If the character '&' is to actually appear in the text, it has to be entered twice.

If an exception object has the attributes LAWYER and PARTNER with the contents 'Smith' and 'Jones', the parameterized exception text of the class:

Chambers &lawyer&&&&partner&

in this object status:

Chambers Smith&Jones

The rules for setting parameters for exception texts using attributes are:

1. If text parameters, which are not attributes in the class, appear in the message, the names of the parameters remain unchanged in the text.
2. If a text parameter, which is an attribute in the object but is not interpretable as a text, appears in the message, the name of the parameter remains unchanged in the text and the attribute type is also specified.
3. If the contents of an attribute to be substituted exceed a reasonable length, they can be truncated (represented by '...').

The exception texts of global exception classes are stored with their various translations in the OTR (Open Text Repository). A text is assigned to an exception class via the TEXTID attribute defined in the CX_ROOT superclass. This attribute contains the globally unique ID of the text object in the OTR in an exception object at runtime. The GET_TEXT method reads this text, may substitute text parameters with the contents of the corresponding attributes, and returns the text as a string.

The exception texts in the OTR are in any language. As soon as GET_TEXT is called up, however, the logon language must be set. For this reason, it always makes more sense to work with the exception object itself within an application, in other words, to forward or store the exception rather than to work with the value returned by GET_TEXT.

The exception texts of global classes are defined on the Texts tab page of the Exception Builder. The Exception Builder generates the corresponding entries in the OTR.

Several texts with individual IDs can be assigned to a class. The Exception Builder generates a standard text for each global class. The unchangeable name of this standard text is the same as the class name. Individual names must be assigned for further texts. For each text, the Exception Builder generates a static constant that contains the associated ID in the OTR. The names of exception texts are, therefore, in the same namespace as the attributes of the exception class and are unique for one path of the inheritance hierarchy. A text can be addressed and identified by means of the static constant, which avoids having to work directly with the OTR in the ABAP program.

The exception text to be used can be determined when an exception is raised by transferring the static constants mentioned above to the IMPORTING parameter TEXTID of the instance constructor. If this text is not defined, the standard text is used. The instance constructor must be programmed accordingly. With global exception classes, the Exception Builder generates the instance constructor so that at least one text is available for each exception. Even if a standard text is not entered, the text of the next possible superclass is used.

The Exception Builder also ensures that the instance constructor has IMPORTING parameters with the same name for the attributes with which the parameters of the exception texts are filled.

With local classes, you have to make these settings yourself.

As well as the message string to be output, the required type must be specified in a type field.