sapdev logo background
sapdev logo sapdev logo
Comments

SAP REACTION ERROR GUIDL documentation, setup help and example usage



Return to SAP documentation index


GUIDELINE 5.8

Reaction to Error Situations

ABAP_BACKGROUND
ABAP provides the following concepts that a program can use to properly react to different error situations:
  • Exceptions

  • Exceptions are events in the execution of an ABAP program that interrupt the program when it is not possible for the program to continue in a meaningful way. Exceptions are raised either by the ABAP runtime environment or with ABAP statements ( RAISE EXCEPTION ) in the program. Exception handling enables you to react to these events. An exception that is not handled results in a runtime error; that is, the program terminates and outputs a short dump that describes the exception.
  • Assertions

  • Assertions formulate conditions in a program that must be met to ensure a proper continuation of the program. An assertion is defined by an
    ASSERT statement.
  • Messages

  • Messages are texts that can contain up to four placeholders for value replacements and that can be displayed or otherwise sent using the
    MESSAGE statement.
    These three concepts either involve the handling of the error situations by the program or the user (exceptions or error messages), or result in a controlled program termination (assertions or exit messages).

    ABAP_RULE
    Select an appropriate reaction to error situations
    Select the appropriate concept of error handling (exception, assertion, or message) for the respective error situation so that the error can either be handled adequately in the further course of the program or is terminated in a controlled manner.

    ABAP_DETAILS
    For each error situation, you should decide on one of the three concepts for error handling:
  • Exceptions are to be used in all unexpected situations that the user does not have under control. These include, for example, invalid parameter values during the procedure call or unavailable external resources, such as files.

  • Assertions are to be used to detect inconsistent program states that necessitate an immediate program termination.

  • Messages are to be used only as dialog messages for error dialogs within the scope of classical dynpro processing (if still available). If you want to implement a program termination in situations where it is not a good idea for the program to continue, use assertions from now on instead of termination or exit messages.

  • The MESSAGE statement is not only used to display dialog messages in a classic dynpro, but can also be deployed to terminate a program in a controlled manner or raise classic exceptions in the MESSAGE ... RAISING variant if the appropriate message type is selected. This invites you to combine the different concepts, which may lead to problems. This can be traced back to the old programming model that was driven exclusively by classical dynpros, in which an error situation directly required the output of a message to the user.
    For contemporary programming that takes the separation of concerns (SoC) into account, the question of whether a message is to be sent to the user in the event of an error can usually only be answered in a higher software layer. The layer in which such an error situation occurs must therefore react with an exception initially, which in turn represents a new situation for a higher layer, to which it can react with a dialog message or any other error message.
    Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved




    RANGES_TABLE_GLOSRY
    READER_STREAM_GLOSRY




    comments powered by Disqus