Exception Texts
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 displayed 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.
Example
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&
becomes:
Chambers Smith&Jones
The rules for setting parameters for exception texts using attributes are:
- If text parameters, which are not attributes in the class, appear in the message, the names of the parameters remain unchanged in the text.
- 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.
- 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 OTR (Open Text Repository). A text is assigned to an exception class using 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 OTR can be in any language. As soon as GET_TEXT is called, 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 in Exception Builder. Exception Builder generates the corresponding entries in OTR.
Multiple texts with individual IDs can be assigned to a class. Exception Builder generates a standard text for each global class. The non-modifiable name of this standard text is the same as the class name. Individual names must be assigned for further texts. For each text, 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 OTR in the ABAP program.
Example of Exception Texts in Exception Builder
The predefined exception class CX_SY_FILE_OPEN_MODE is used by the runtime environment to refer to exceptions when a file is not opened or not opened in the correct mode. Apart from the standard text, the class contains three further texts called READ_ONLY, NOT_OPEN and INCOMPATIBLE_MODE, which enable the exception to be handled more specifically without further subordinate classes having to be created immediately.
Exception Texts and Constructors
The exception text to be used can be determined when an exception is raised by passing 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. In the case of global exception classes, 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.
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.
In the case of local classes, you have to make these settings yourself.
Although the exception texts are not primarily designed for interaction with the end user, it may, in certain cases, be worth displaying them as messages . For this purpose, the MESSAGE statement has been modified to enable any strings to be displayed:
MESSAGE string TYPE type.
As well as the message string to be displayed, the required type must be specified in a type field.
report DEMO_EXCEPTION_TEXT.
data OREF type ref to CX_SY_FILE_OPEN_MODE.data TEXT type STRING.
try. raise exception type CX_SY_FILE_OPEN_MODE exporting TEXTID = CX_SY_FILE_OPEN_MODE=>READ_ONLY FILENAME = `DUMMY.DAT`. catch CX_SY_FILE_OPEN_MODE into OREF. TEXT = OREF->GET_TEXT( ). message TEXT type 'I'.endtry.
try. raise exception type CX_SY_FILE_OPEN_MODE exporting TEXTID = CX_SY_FILE_OPEN_MODE=>NOT_OPEN FILENAME = `DUMMY.DAT`. catch CX_SY_FILE_OPEN_MODE into OREF. TEXT = OREF->GET_TEXT( ). message TEXT type 'I'.endtry.
try. raise exception type CX_SY_FILE_OPEN_MODE exporting TEXTID = CX_SY_FILE_OPEN_MODE=>INCOMPATIBLE_MODE FILENAME = `DUMMY.DAT`. catch CX_SY_FILE_OPEN_MODE into OREF. TEXT = OREF->GET_TEXT( ). message TEXT type 'I'.endtry.
In this example, the predefined exception CX_SY_FILE_OPEN_MODE is raised and caught three times. The three exception texts of the class are used one after the other and their FILENAME parameters supplied using various parameter passes to the instance constructor.