Skip to Content
Author's profile photo Petr Plenkov

How to use messages properly in the code. Common rules.

Dear all,

Today I’m going to discuss message handling with you.

So basically message code – this is something important to a support team. When we have this code we can navigate to SE91 and by using where-used-list for the message to find all the places in the code where this message occurs. However developers sometimes don’t care about future support issues and make fast solution based just on a text:

  • message ‘Some message’ type ‘S’

In this case we have a generic message without having long text description at all. To find the reason of such a message is rather more diffciult debugging task than when having a code.

Rule #1: Use message code as much as you can. 

Instead of direct text try to use SE91 message number.

These are pretty simple steps to find out the reason of the message:

1. Double click on the message in the buttom of the screen or F1 key for the popup message of type ‘I’.

2. We go to a technical information


3. In the popup window we double click on the message number


4. Put the cursor on the message number and go to the Where-Used-List (Ctrl+Shift+F3)


5. Now execute the search and all the possible places where message can occur

Rule #2. Try to keep the number of places with the same message code very low

I guess you know very well the case when you have some standard SAP message, you look for place where it’s been called  and you have like a list of dozens diffirent programs with the same code. That’s very difficult to find the place where you certain message occured.

In common words I would cover this rule with more abstract one:

Rule #2.1 Don’t copy the same code twice.

Even it’s just message call, but you’re going to use it widely – provide some program unit for that.

Rule #3. Use static dummy message calls while dynamic message declaration when it’s possible.

Sometimes we do not need to output message immediately but to store it into some log.

So in the code like this:

  CLEAR ls_msg.
      ls_msg-msgty     = 'I'.
      ls_msg-msgid     = 'FMFEES'.
      ls_msg-msgno     = '68'.
      ls_msg-probclass = '3'.
          i_log_handle = iv_log_handle
          i_s_msg      = ls_msg.

Just don’t forget to add a very simple but so important line:

message 068(fmfees) into data(lv_dummy).

This tiny 5 seconds effort can save up even hours to a person who will probably debug your code.

Rule #4. When creating an own exceptions that are going to be used as output messages implement IF_T100_MESSAGE.

As example you can check CX_SALV_X_MSG class.


In opposite, if you perform steps from Rule #1, you’ll navigate to this class.

Please notice that in this case once the exception has been caught:

catch cx_salv_x_msg into data(lo_cx).

you should output the message not like this:

message lo_cx->get_text( ) type ‘S’.

but like this:

message lo_cx type ‘S’.

In the case you have only abstract cx_root instance you can try the following apporach:

Advanced navigation to a source code from the message long text.

Rule #5. Use long text explanation.

Despite source code navigation is an important thing, don’t forget that the main goal of our message is to explain the reason of the error to the end user. Properly documented software can let users sort the problem out even without contacting support team at all, that automatically moves your software on the next level of quality.

Therefore remove self-explanatory checkbox and provide some key details for the user how to get rid of this message by his own.

By following this simple rules you can provide rather better solution.

I hope you liked it.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi Petr,

      Spot on!  Clear guidance on a regularly overlooked topic.

      If I could offer a 4th rule: Messages are rarely self-explanatory, uncheck the box and add some meaning extra information.



      Author's profile photo Petr Plenkov
      Petr Plenkov
      Blog Post Author

      Very good point! Must be added for sure.

      Author's profile photo Lars Hvam
      Lars Hvam

      Hi Petr,

      Nice blog, I've added your recommendations to

      ZCL_AOC_CHECK_37 · larshp/abapOpenChecks Wiki · GitHub

      And added logic to check for the

      MESSAGE lx_err->get_text( ) TYPE 'S'


      Author's profile photo Petr Plenkov
      Petr Plenkov
      Blog Post Author

      thanks Lars. i checked your page. Just keep in mind: this check should be applied to only those instances that can be casted to if_t100_message:


      cast if_t100_message( lo_cx ).

      " Here you can do your check.

      catch cx_sy_move_cast_error.


      Author's profile photo Lars Hvam
      Lars Hvam

      true, however I dont have the code to determine the object types. Thinking that if code contains something like "MESSAGE lo_obj->get_text( )" then most likely there is something else wrong, and perhaps exceptions should be used instead.