Skip to Content

As in the previous post, this one is a trapdoor to be avoided by framework and toolkit designers rather than their users.

STRINGs are available in ABAP since 4.6A (how many of you remember working on that release, btw?), and many developers seem to think of STRINGs as the one and only way to transport text-like data around in an ABAP program. I can only speculate about the reasons – perhaps it’s because for most developers, ABAP isn’t the first programming language and in other languages, Strings are the common instrument to handle textual data. Some long-time ABAP developers might also have jumped on STRINGs  because they are easier to use than the traditional C fields – you don’t have to think about the maximum length of the value any more. In many programs and frameworks, I’ve seen the following pattern:

METHODS: do_something IMPORTING i_text TYPE string.

Don’t get me wrong – there’s nothing bad about using STRINGs where they are appropriate, but in many cases, they are not required and can even annoy the users of your framework. For example, while the following invocations can be used…

DATA: l_string TYPE string VALUE 'Foo Bar'.
lr_instance->do_something( 'Foo Baz' ).
lr_instance->do_something( `     Bar Baz     ` ). " my preciousss spacesss
lr_instance->do_something( l_string ).

…some other, rather common parameter types won’t work:

TYPE-POOLS icon.
DATA: l_text TYPE c LENGTH 100.
lr_instance->do_something( l_text ).
lr_instance->do_something( 'Foo Bar'(001) ).
lr_instance->do_something( icon_red_light ).

One might argue that this is a problem of the implicit type conversion not being able to handle some common cases, but for those of us who can’t tweak the language itself, that’s no consolation. Having to work around this limitation invariably raises the blood pressure of the developer and leads to really messy code like this:

DATA: lr_function TYPE REF TO cl_salv_function,
      l_string    TYPE string.
* ...
l_string = 'Baz Bar'(042).
lr_function->set_text( l_string ).
l_string = icon_red_light.
lr_function->set_icon( l_string ).
l_string = 'Tooltime Fooltime'(084).
lr_function->set_tooltip( l_string ).

Fortunately, there’s a simple rule of thumb to avoid this: For IMPORTING parameters, use CSEQUENCE as a type unless you really need a STRING. You can still use STRING variables and attributes to process the data internally, but the users of your method are free to choose the data type passed to the actual parameter.

As you can see in the example above, this is a fairly common problem. Even in the SALV framework you can find methods that require you to perform manual type conversion. But since it’s easily avoided, please give both the binary kittens and your fellow developer’s coronary arteries a thought and choose your parameter types wisely.

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Vinod Kumar
    Good one Volker. One of best blog series for ABAP. This one prompted us to change some part of re-usable code library before moving to production.

    But surprised to see some of SAP Standard classes (commonly used) uses STRING as importing parameter.

    Regards, Vinod

    (0) 
  2. Kumud Singh
    Hello,
    I enjoyed the example in my system.
    I could also use CLIKE instead of CSEQUENCE.
    Rather than memorizing these generic data types what I would learn is when coding and facing an issue google (which ultimately leads to SAP sites), if an alternative exists.

    Regards,
    Kumud

    (0) 
    1. Volker Wegert Post author
      Kumud,

      CLIKE is not CSEQUENCE. CSEQUENCE is either C or STRING, whereas CLIKE also allows dates, times, numerical characters and character-only flat structures. This is an important distinction (that I failed to blog about :-))

      The problem with googling for ABAP stuff is that you’ll get a lot of really outdated information.

        Volker

      (0) 
      1. Kumud Singh
        Thanks again.
        That was the precise reason,I said that I could use CLIKE instead of CSEQUENCE!(all char. types would be supported!).

        “Google giving outdated info”- but I can bet majority of developer community rely on it!
        Good for me that I have now realized importance of reading SAP-PRESS books!

        Regards,
        Kumud

        (0) 
      2. Clemens Li
        Thanks Volker for the blog (though the introductory text about ABAP kernel killing IT animals was not very clear) and Thanks KUMUD SINGH for the clarification.

        In situations like the one discussed I already got used to declare with TYPE ANY – but feeling queasy about risking a dump for inappropriate use.

        Now I know CLIKE and CSEQUENCE (seen them but did not really kniow whats it about), personally I’d prefer the CLIKE alternative because it is more general.

        Regards,

        Clemens

        (0) 
  3. Michelle Crapo
    I’m one of those developers that use code just about exactly like the last example!  It will make things a lot easier in the future.  Yet another bookmark for SCN!  I’ll have to start using CSEQUENCE.  The only way I remember is by using.

    Why do I use string?  I never knew there was an alternative.  Just because you asked. πŸ™‚

    Michelle

    (0) 
    1. Vinod Kumar
      Very informative blog.

      When I used STRING as importing parameter in one of the custom re-usable method, I thought,when standard class CL_GUI_FRONTEND_SERVICES uses it, why can’t I ? 

      As you said, best way to remember CSEQUENCE is by using it. πŸ™‚

      Regards, Vinod
      Regards, Vinod

      (0) 
  4. Thorsten Franz
    Hi Volker,
    Excellent blog! If there was a category of must-read blogs for any ABAP developer, I would definitely nominate the post. πŸ™‚
    Cheers,
    Thorsten
    (0) 
  5. Robert Voppmann
    Do you have a solution for using generic types such as clike or csequence in raising exceptions?

    Quite often I am annoyed about having to convert my parameters before raising an exception like

    raise exception type zcx_foo
    exporting message = l_(something) …

    (0) 
    1. Volker Wegert Post author
      Robert,

      the only thing that springs to mind would be a static method RAISE in your exception class that performs the conversion.

      Then again, a method RAISE_textname for every text would be nice… with input parameters for only the variables that are used in the text…

      …hmm, we’ve got all this information in structured form, we could generate this automatically…

      *sigh* So many ideas, so little time…

        Volker

      (0) 
    2. Volker Wegert Post author
      Robert,

      the only thing that springs to mind would be a static method RAISE in your exception class that performs the conversion.

      Then again, a method RAISE_textname for every text would be nice… with input parameters for only the variables that are used in the text…

      …hmm, we’ve got all this information in structured form, we could generate this automatically…

      *sigh* So many ideas, so little time…

      Volker

      (0) 
    1. Thomas KrΓΌgl

      I didn’t check the conversions to string for those examples explicitly, but with the constructor expression CONV the conversion now should at least be more readable, avoiding the helper variables πŸ™‚

      Still a valid point to check if string is really the best thing to use of course.

      (0) 

Leave a Reply