ABAP Keyword Documentation → ABAP Programming Guidelines → Architecture → Error Handling
Other versions: 7.31 | 7.40 | 7.54
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 is the main element for using messages. This statement sends a message; by specifying a message
type, you can define the display type and subsequent program behavior. For this reason, a distinction is made between the following message types:
- Status message (S)
- Information message (I)
- Warning (W)
- Error message (E)
- Termination message (A)
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:
MESSAGE ... RAISINGstatement is a combination of the statements,
RAISE, which enables you to link classical exceptions with messages.
- Using the special, predefined classical exception,
error_message, you can handle error and termination messages (that occur when function modules run) in the same way as exceptions. This also applies to messages sent from the ABAP runtime environment (for example, when the automatic input check of classical dynpros is running).
- In exception classes, you can define exception texts with a reference to messages. The message types A and X can also be used for direct program termination.
Only use messages for error handling in classic 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.
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
the context of classical dynpro processing. The predefined exception,
should be regarded as a workaround that enables you to execute procedures for sending messages in the application layer or in the background.
In new programs, the use of messages should be restricted as described below.
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
CHAIN statements of the dynpro flow logic.
You can use messages as exception texts and send them to the program user. This primarily involves exceptions in the presentation layer.
MESSAGE statement 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, you must specify a reference to an object whose class includes the IF_T100_MESSAGE interface.
In addition, messages in procedures where classical exceptions are still necesary can replace real exception
texts: Use the
MESSAGE ... RAISING
statement instead of
During this process, information on the exception text is transferred to the handler, in the system
These fields filled using the
MESSAGE statement. This works especially well for handling exceptions during an RFC, for which class-based exception handling is not possible.
Message types A and X cause program terminations and should no longer be used:
- If you send a termination message of type A, the
ROLLBACK WORKstatement is executed implicitly. This can lead to unexpected results, if the message is handled with
error_messageas a classical exception (rather than causing a program termination). To be on the safe side, you should explicitly use the statements
LEAVE PROGRAMto exit the program.
- If you send a message of type X, the program is terminated with the
MESSAGE_ TYPE_Xruntime error. Due to internal inconsistencies, you should now use assertions for forced program terminations. The values transferred using the
FIELDSaddition of the
ASSERTstatement are usually better suited to problem analysis than a message.
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, you should no longer use exit messages. Instead, you should specify a logical condition in
ASSERT that is always false.