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

[pepl]

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'.

      CALL FUNCTION 'BAL_LOG_MSG_ADD'

        EXPORTING

          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.

Adios.