ABAP Keyword Documentation →  ABAP Programming Guidelines →  Architecture →  Error Handling → 

Messages

Background

Messages are texts that are created using the message maintenance (Transaction SE91). They are stored in the T100 system table. In ABAP programs, the statement MESSAGE is the main element for using messages. This statement sends a message; by specifying a message type, the display type and subsequent program behavior can be defined. For this reason, a distinction is made between the following message types:

In addition, there is a special message type, exit message (X), which causes a targeted program termination with a runtime error.

The actual system behavior after a message is sent is highly context-dependent. The current version of the ABAP keyword documentation contains a detailed list of effects caused by different message types in different contexts (such as dialog processing, background processing, during an RFC and during the processing of HTTP requests).

The originally purpose of messages is to act as dialog messages, in order to display short information (types I and S) and handle incorrect user input (types W and E), during classical dynpro processing. Messages also have aspects that overlap with exceptions:

Rule

Only use messages for error handling in classical dynpros and as exception texts

Only send dialog messages during PAI processing of classical dynpros. Messages should only be used as exception texts and should no longer be used anywhere else. In particular, messages should no longer be used to force program termination.

Details

The wide use of messages for different purposes can be traced back to the previous programming model, which was only driven by classical dynpros. Here, an exception situation usually always required the direct output of a message to the user. This concept was adopted for other situations, such as targeted program terminations. Triggering a dialog message within application logic procedures violates the SoC principle and limits the usability of the relevant procedure (Method) to the context of classical dynpro processing. The predefined exception error_message should be regarded as a workaround that enables procedures to be executed for sending messages in the application layer or in the background.

In new programs, the use of messages should be restricted as described below.

Dialog messages

In cases where classical dynpros are still used, message types E, I, S, and W are still suitable for sending information to the user or for running error dialogs at the time of PAI (which is the original purpose of these messages types). Running error dialogs, in particular, is supported by the statements FIELD and CHAIN of the dynpro flow logic.

Exception Texts

Messages can be used as exception texts and sent to the program user. This primarily involves exceptions in the presentation layer.

The statement MESSAGE allows these exception texts to be sent directly as dialog messages. A reference to a corresponding exception object can be specified directly. From a technical point of view, a reference must be specified to an object whose class includes the interface IF_T100_MESSAGE.

In addition, messages in procedures where classical exceptions are still necessary can replace real exception texts; use the statement MESSAGE ... RAISING instead of RAISE. During this process, information about the exception text is passed to the handler, in the system fields sy-msgid and sy-msgv1 - sy-msgv4. These fields are filled using the statementMESSAGE . This works especially well for handling exceptions during an RFC, for which class-based exception handling is not possible.

Program terminations

Message types A and X cause program terminations and should no longer be used:

Exception

Exit messages can still be used, if it is absolutely necessary to display message text in the short dump of the runtime error. However, this should not be misunderstood as communication with the user. A runtime error is not a suitable way of communicating with users. For a simple, unconditional program termination, however, exit messages should no longer be used. Instead, wherever necessary, a logical condition that is always false should be specified in ASSERT.