Skip to Content

DO and DO

Personally I hate nested IF … ENDIF. Suppose the following:

READ TABLE some_table WITH KEY ... IF sy-subrc = 0.    READ TABLE some_other_table WITH KEY ... </li>  IF sy-subrc = 0.</li>    READ TABLE another_table WITH KEY ... </li>    IF sy-subrc = 0.      ... etc, etc..    ENDIFENDIF.ENDIF.

“Most disturbing, sir” as Jeevse could put it. Very unpleasant.

And the idea’s come. Now instead of nested IF’s I use DO..ENDDO, just as follows:

DO 1 TIMESREAD TABLE some_table WITH KEY ...   CHECK sy-subrc = 0.    READ TABLE some_other_table WITH KEY ...   CHECK sy-subrc = 0.  READ TABLE another_table WITH KEY ...   CHECK sy-subrc = 0.  ... etc, etc..ENDDO.

That’s it. What do you think?

You must be Logged on to comment or reply to a post.
  • Yep, that’s quite nice.  It certainly makes the code easier to read and thus maintain.  It’s initially distracting as to why a DO loop has been used, but once a support team is aware of the convention, it would hardly even be noticed.
      • Hi Sergei,

        It took me quite some time to realise, the need for DO …ENDDO. Let me know if it is still right, the use of CHECK , when it fails, just comes out of the loop, not out of the program.

        So according to this logic, the error message would be say
          a) because of 1st read fail
          b) because of 2nd read fail
          c) because of 3rd read fail

        and note exactly pinpoint. That would do I guess.

        Yes we can put better error messages.

        Thanks for sharing this, and as Scott rightly pointed out, this should do “barely okay” with support team.

        Subramanian V.

        • Hi Subramanian,
          CHECK does not come out of the loop, it  strictily goes to the next step of it, literally it equals to

          IF sy-subrc NE 0.

          And as in my case we have only one step in loop (DO 1 TIMES) then this is the equivalent of the exit. Actually, one can use TRY ENDTRY for the same purpose, but seems that the overhead of OO-exceptions would be slightly more than adequate.

          Regards, Sergei

  • I don’t really like DO..ENDDO…but in this case I have to admit it’s a cool idea…and it really improves code readability.

    Thanks for the tip, hope you have other cool ones.


  • You could do the same with a form routine. Maybe even better to read and understand. Ok, you need to sort out the parameters but otherwise it’s the same.
    But a great idea, I like it.

    That reminds me of a strange CASE I’ve seen:

    CASE ‘X’.
      WHEN FLAG_1. …
      WHEN FLAG_2.
      WHEN FLAG_3.

    Best regards

    • Thanks Dirk,
      Some 20 years ago I used to write programs on a proprietary ALGOL-like language, and there was a so-called static exceptions: something like TRY.. ENDTRY with explicit declaration of an exception and without generating exception instance when firing (just conversion into simple GOTO). The construct was very useful and readable. Would be nice to use something similar in ABAP.
  • Hi,

    in my eyes this is bad programming practice.

    1. What do you do with error handling?
    Normally you should use the else statement to do some error handling or write log entries so that one can reproduce why a program worked as it did.

    2. You have no overview about the program flow.
    Where did your program leave the do loop? You can only get it in the Debugger.

    Sorry for that bad judgment but I´m basically a Java developer with also some years of programing practice in ABAP and things like this always bothered me.


    • Hi Helmut,
      Certainly this is not an ideal pattern to use everywhere instead of nested IF’s, I use it more-or-less locally just to make some fragments more readable (to me at least). There are some cases where there is no need to perform thorough error handling after each statement.
      It is essential to use 1 TIMES clause in this sample as it garantees that DO loop would have only one pass. In that case you can treat DO 1 TIMES as BEGIN and ENDDO as END.
      I admit that e.g. OO exceptions are much more powerful and readable but they have (as far as I know) essential overhead – instance creating, propagation etc.
      • Hi Sergei,

        if you don’t want to, there is not an essential overhead with class based exceptions!

        As long as you don’t use INTO behind CATCH, there is no exception object created.



        • Thanks Horst!
          Ceratinly I experience some lack of knowledge of insides of OO exceptions. Could you provide some info on rasing exception overhead? If it’s comparable with DO…CHECK…ENDDO, than it is certainly worth to switch to.

          Regards, Sergei