GUIDELINE 5.17
Messages
ABAP_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:
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:
The statement MESSAGE ... RAISING is
a combination of the statements MESSAGE and RAISE which
enables classical exceptions to be associated with messages.
Using the special, predefined classical exception, error_message ,
error and termination messages (that occur when function modules run)
can be handled 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, exception texts
can be defined with a reference to messages. The message types A and X
can also be used for direct program termination.
ABAP_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.
ABAP_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 b
ackground.
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 statement MESSAGE . 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:
If a termination message of type A is sent, the statement ROLLBACK
WORK is executed implicitly. This can lead to unexpected results, if
the message is handled with error_message as a classical
exception (rather than causing a program termination). To be on the safe
side, the statements ROLLBACK WORK and LEAVE PROGRAM
should be used explicitly to exit the program.
If a message of type X is sent, the program is terminated with the
runtime error MESSAGE_ TYPE_X . Due to internal inconsistencies,
assertions should now be used for forced
program terminations. The values passed using the addition FIELDS
of the statement ASSERT are usually better suited to problem
analysis than a message.
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 .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved