topic Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable in Application Development and Automation Discussions

Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Jelena_Perfiljeva — Thu, 09 Jan 2020 17:32:54 GMT

This is in ECC EHP6 ABAP 7.31 system. I've created a global exception class using IF_T100_MESSAGE interface. This exception class will be used in the local methods that will validate the selection screen fields. These methods will raise an exception (using this new exception class) and pass different message ID, number, etc. through it so that an appropriate error message can be displayed on the selection screen.

DATA: screen_error TYPE REF TO zcx_sel_screen_error.
TRY.  
validate_input( ... ).
CATCH zcx_sel_screen_error INTO screen_error.    
MESSAGE screen_error TYPE 'E'.
ENDTRY.

Within validate_input(), we call another local method raise_exception with one or more parameters to raise an exception with the context-appropriate messages. This is how the exception is raised:

METHOD raise_exception.
 DATA error_message LIKE if_t100_message=>t100key.
error_message-msgid = 'Z...'.
 error_message-msgno = i_msgno.
 error_message-attr1 = i_text1.
 error_message-attr2 = i_text2.
 error_message-attr3 = i_text3.
 error_message-attr4 = i_text4.
 RAISE EXCEPTION TYPE zcx_sel_screen_error
 EXPORTING  textid = error_message.
ENDMETHOD. "raise_exception

This works wonderfully but I ran into a strange issue when the message text attribute (ATTR1) is a numeric variable, either type N or I. The problem is that the message text shows ampersands with the number, like this:

This doesn't happen if I straight up use a numeric variable with MESSAGE command. A "brute force" approach would be to have an intermediate text type variable and just move numeric value in it before calling the exception method but I'm hoping to avoid this. (Note: I'm using TYPE ANY for ATTR1...4 in the method definition because the type used in the interface causes a syntax error with a numeric variable. Not very happy about that part either but it's not the main issue.)

Am I doing something wrong and are there any possible (and reasonably simple 🙂 ) solutions other than a "brute force" one? Thank you!

P.S. Before anyone suggests, IF_T100_DYN_MSG does not exist in 7.31.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Sandra_Rossi — Thu, 09 Jan 2020 19:09:18 GMT

I know I'm using a recent 7.52 system, but just in case, if you try this code (not sure if it works), do you see "Entry 23 exists (entry is correct)" or "Entry &23 & exists (entry is correct)"?

If it works and you see the first one, then maybe you can compare what is different between your case and this one.

CLASS lcx_t100 DEFINITION INHERITING FROM cx_static_check.
  PUBLIC SECTION.
    INTERFACES if_t100_message .
    METHODS constructor.
    CONSTANTS:
      BEGIN OF zcx_t100,
        msgid TYPE symsgid VALUE '00',
        msgno TYPE symsgno VALUE '057',
        attr1 TYPE scx_attrname VALUE 'AA',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF zcx_t100.
    DATA aa TYPE i.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.
CLASS lcx_t100 IMPLEMENTATION.
  METHOD constructor.
    CALL METHOD super->constructor.
    CLEAR me->textid.
    aa = '23'.
    if_t100_message~t100key = zcx_t100.
  ENDMETHOD.
ENDCLASS.
PARAMETERS dummy.
AT SELECTION-SCREEN.
  DATA(exception) = NEW lcx_t100( ).
  MESSAGE exception TYPE 'E'.<br>

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Former Member — Thu, 09 Jan 2020 19:24:58 GMT

I recall encountering this kind of problem. You suppose to pass the name of the attributes of the exception class holding the message parameters, not directly the parameter values themselves.

DATA: textid    LIKE if_t100_message=>t100key,
      exception TYPE REF TO zcx_my_error.

textid-msgid = msgid.
textid-msgno = msgno.
textid-attr1 = 'PARAMETER1'.
textid-attr2 = 'PARAMETER2'.
textid-attr3 = 'PARAMETER3'.
textid-attr4 = 'PARAMETER4'.

CREATE OBJECT exception
   EXPORTING
      textid = textid.

exception->parameter1 = msgv1.
exception->parameter2 = msgv2.
exception->parameter3 = msgv3.
exception->parameter4 = msgv4.

RAISE EXCEPTION exception.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Ryan-Crosby — Thu, 09 Jan 2020 19:44:24 GMT

Hi Jelena,

It appears that this is by design if the system determines that it cannot convert ATTR1-4 to a placeholder text. Here is the screenshot from the help - so it seems you would have to do some form of conversion prior to raising the message into an appropriate character type to avoid this issue.

Regards,

Ryan Crosby

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Ryan-Crosby — Thu, 09 Jan 2020 20:02:08 GMT

Yep, after checking this a bit further this is the issue. The system is trying to pass a pointer to the argument name and it cannot be found. Thus it takes the parameter name (which is the value in your case) and is then assigning that to a field symbol and surrounding it with & characters. Check the method CL_MESSAGE_HELPER=>SET_SINGLE_MSG_VAR for how attributes and values are processed and it should clear it up for you. Sorry - tagging jelena.perfiljeva2 here.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Former Member — Thu, 09 Jan 2020 20:16:01 GMT

ryan.crosby I remember debugging it having no clue why the strange behavior.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Jelena_Perfiljeva — Thu, 09 Jan 2020 20:18:58 GMT

Ah, I get it now, thanks! Typical case of RTFM, lol. 🙂 I was looking at the examples in the documentation but somehow didn't connect the dots that 'TEXT' meant the name of attribute.

Well, this kind of sucks... I thought this was simpler. 😞 I guess I'll just have to read MSGNO, MSGID etc. values instead of using a reference with MESSAGE. Oh well.

Thank you!

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Ryan-Crosby — Thu, 09 Jan 2020 20:22:23 GMT

Haha, well the documentation and examples could also be clearer which isn't always the case. jelena.perfiljeva2 - On a side note I think Gabor's answer is more reflective of the correct answer even though mine was pointing in the general direction.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Ryan-Crosby — Thu, 09 Jan 2020 20:36:06 GMT

jelena.perfiljeva2 - One thing you could do here is to statically create the variables for the attribute names as something like V1-V4 and give them the type ANY. Then, when you raise the exception you just add those 4 variables and they will be included automatically. Something like the following:

METHOD raise_exception.
DATA error_message LIKE if_t100_message=>t100key.
error_message-msgid ='Z...'.
 error_message-msgno = i_msgno.
 error_message-attr1 = 'V1'.
 error_message-attr2 = 'V2'.
 error_message-attr3 = 'V3'.
 error_message-attr4 = 'V4'.
RAISE EXCEPTION TYPE zcx_sel_screen_error
 EXPORTING  textid = error_message
            v1     = i_text1
            v2     = i_text2
            v3     = i_text3
            v4     = i_text4.
ENDMETHOD."raise_exception

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Former Member — Thu, 09 Jan 2020 20:41:26 GMT

ryan.crosby You can go one step further in simplification by taking the message parameters from SY to reduce typing effort and also provide cross-reference for the message class. So you can write this:

MESSAGE e001(zmy_messages) WITH '10' INTO dummy.

zcx_my_message_class=>raise_from_sy( ).

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Jelena_Perfiljeva — Thu, 09 Jan 2020 22:38:55 GMT

sandra.rossi - thanks for a reply! I had to make a small change to downport inline declaration and after that I got "Entry 23 exists (entry is correct)". As Ryan correctly pointed out in his (now accepted) answer, I misunderstood the design of MESSAGE using a reference. ATTR1...4 is supposed to be the name of a class attribute (such as 'AA' in your example), not just a value. In my example, I was simply calling raise_exception with i_text1 = max_orders (max_orders type i). (This is actually spelled out in documentation, even in 7.31 but who reads, right? 🙂 )

Thank you anyway! This was enlightening.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Jelena_Perfiljeva — Thu, 09 Jan 2020 22:41:01 GMT

Thank you for the answer! I could "accept" only one but this is also correct. I should've just read documentation more carefully.

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Jelena_Perfiljeva — Thu, 09 Jan 2020 22:50:38 GMT

gabmarian - I'm actually a big fan of using MESSAGE like that and sy variables (as a bonus, this triggers "where used" for the message) but wouldn't the "purist" camp object to that approach? I always hear how using system variables is bad or something. Keeping a balance between what's efficient/practical and what's clean/proper is a daily struggle for me. 🙂

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Jelena_Perfiljeva — Thu, 09 Jan 2020 22:55:49 GMT

Ryan - both answers here are correct in their own way, it was a coin toss and you won. Enjoy your karma points. 🙂

Re: Problem in MESSAGE using exception class with IF_T100_MESSAGE and a numeric variable

Former Member — Thu, 09 Jan 2020 23:15:26 GMT

jelena.perfiljeva2 - I also prefer to avoid sy components except the message related ones (and of course subrc 🙂 ). Until the recent introduction of the syntax element RAISE EXCEPTION ... MESSAGE ... i always opted to handle messages in OOP context this way. I haven't really find any disadvantage of this form yet, but even if exists the cross-reference should compensate for it. I found where use list worth like gold when a user ask to investigate an error randomly popped up.
But maybe someday someone will persuade me of the opposite. 🙂