Entering content frame

Exception Texts Locate the document in its SAP Library structure

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.

Attributes as Parameters in Exception Texts

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&

in this object status:

Chambers Smith&Jones

Rules

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 '...').

Managing Exception Texts

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.

Creating Exception Texts

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.

Example of Exception Texts in the Exception Builder

The predefined exception class CX_SY_FILE_OPEN_MODE is used by the runtime environment to refer to exceptions during file access for which the file was not opened or simply 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 transferring the static constants mentioned above to the IMPORTINGparameter 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.

Outputting Exception Texts

Although the exception texts are not primarily designed for interaction with the end user, it may, in certain cases, be worth outputting them as messages. For this purpose, the MESSAGE statement has been extended to enable any strings to be output:

MESSAGE string TYPE type.

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

Example

Example

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 passings to the instance constructor.

 

Leaving content frame