Streamlining Message and Exception Handling

This topic discusses approaches for streamlining message handling within your infotype.

Note Note

The information presented in this topic exceeds the general knowledge that is required to create (or migrate) infotypes in(to) this release. Individuals who have particular expertise in this subject matter or who desire deeper knowledge of this issue may nonetheless consult this topic for reference.

End of the note.

To encode message handling in the most expedient manner possible, we recommend that you refrain from using macros, as other methods exist to achieve shorter calls.

Example Example

The following example demonstrates one option to streamline message handling.

DATA dummy(1) TYPE c.(...) * 055 Make an entry in all require fields MESSAGE ID '00' TYPE 'E' NUMBER '55' INTO dummy. MOVE-CORRESPONDING sy TO msg. APPEND field_name TO field_list. CALL METHOD message_handler->add_message EXPORTING message = msg field_list = field_list cause = if_hrpa_message_handler=>infotype_specific.

If you elect to use this option, then you need not concern yourself with output conversion, because the system will populate the SY variables correctly.

A second option to streamline message handling concerns the field list; rather than specifying the following source code …

APPEND ‘P4711-FIELD1’ TO field_list. APPEND ‘P4711-FIELD2’ TO field_list. APPEND ‘P4711-FIELD3’ TO field_list. APPEND ‘P4711-FIELD4’ TO field_list.

… you may instead specify either of the following two alternatives:

SPLIT ‘P4711-FIELD1 P4711-FIELD2 P4711-FIELD3 P4711-FIELD4 ’AT space INTO TABLE field_list.

SPLIT‘P4711-FIELD1 ’ &‘P4711-FIELD2 ’ &‘P4711-FIELD3 ’ &‘P4711-FIELD4 ’ AT space INTO TABLE field_list.

End of the example.

As you consider the most expedient manner for your infotype to handle messages, keep in mind that the system assumes that all exceptions will be handled by the class-based exception mechanism, and that all exceptions truly are, in fact, exceptional, rather than mechanisms, for example, to set return values with a global variable. Because of these underlying assumptions, you should never misuse exceptions to indicate expected results, but rather only to indicate that an exceptional situation has occurred, in response to which the system may issue a short dump.

Review the following criteria to determine whether your infotype, depending upon the corresponding situation, should issue an error message or an exception.

Under the following circumstances, an error message should be issued.

A deviation from standard processing is required.
Processing of data should not be interrupted.
The problem is likely to be caused by user input.
The problem can be corrected by the user.
The problem is expected to happen on a regular basis.

In contrast, under the following circumstances, an exception should be used.

The problem is caused either by erroneous source code or by erroneous database entries.
The problem is not expected to happen on a regular basis. Once the problem does occur, the application must determine whether or not it can recover. In severe cases, where recovery is impossible, the system may issue an exception to interrupt any subsequent processing (that is, dump). Determination of whether recovery is possible therefore should not be performed in low-level routines.

To summarize, it is important that you avoid confusing exceptions with messages or status indicators, and vice versa. Only occurrences that would merit an entry in the system log should be considered as exceptions.

Example Example

The following examples are intended to help you distinguish situations that require genuine exceptions from situations that merely require error messages.

Exception CX_HRPA_INVALID_DATABASE is used to indicate the presence of corrupt database entries, which merits a genuine exception, rather than an error message.
Exception CX_HRPA_INVALID_INFOTYPE indicates that entries are missing from the Infotypes - Dialog/Database Assignment or Infotypes: Customer-Specific Settings tables (T777D or T582A, respectively). However, because situations exist in which this exception should not be used – as when a user, for example, enters an invalid number while attempting to display an infotype – an error message is generally more appropriate than a genuine exception. The exception CX_HRPA_INVALID_INFOTYPE , in fact, should only be applied when an infotype – for example, the Organizational Assignment infotype (0001) – is expected to be present, but its table entries are absent.

End of the example.