Skip to Content
Technical Articles
Author's profile photo Jacques Nomssi Nzali
Jacques Nomssi Nzali
April 9, 2020 2 minute read

UNTIL Considered Harmful

A Case Against the UNTIL Statement would have been accurate, but I could not pass on using a famous phrasal template.

Conditional Iteration with UNTIL

An ABAP language element implements a concept needed to solve a problem in the developer mind. After a learning period, the developer will absorb the pattern and intuitively, effortlessly express a solution in term of the ABAP statement. The statement becomes part of the formal language used to describe a solution that other developers can read and understand.

The VALUE #( FOR .. THEN ..UNTIL ) expression works well in most cases, it is intuitively understood as a LOOP statement where you can control the index so it has the potential to be widely used.

But I have found one case where this model is broken. So when FOR UNTIL becomes pervasive in code, it will be used without discrimination and there will be cases where the intuition will be wrong, so it it can be Considered Harmful.

Challenge

Evaluate the following pseudo code. What do you expect for N = 0 ?

DATA(iota) = VALUE table_of_integer( FOR idx = 0 UNTIL idx = N ( idx ) ).
  • For N = 5, we create the table iota = #( ( 0 ) ( 1 ) ( 2 ) ( 3 ) ( 4 ) ).
  • For N = 2, we create the table iota = #( ( 0 ) ( 1 ) ).
  • For N = 1, we create the table iota = #( ( 0 ) ).

Scroll down for the solution.

The UNTIL behavior is documented:

  • If the iteration variable var has a numeric data type, or the variable is of type d or t, THEN expr is optional. If THEN expr is not specified explicitly, THEN var + 1 is added implicitly or the value of the iteration variable is increased by 1 for every iteration.
  • If the termination condition is specified after UNTIL, the logical expression log_exp is evaluated after every iteration step. If the result of the logical expression is true, the iteration is ended. At least one iteration step is executed.

So in FOR .. UNTIL loops, at least one iteration step is executed. In the example above, if N = 0 or -1, -2 actually for any value less than the start value, our test for equality yields an endless loop because the iteration is always executed at least once.

Problem

Note this does not happen with a FOR .. WHILE expression

  • If the termination condition is specified after WHILE, the logical expression log_exp is evaluated after every iteration step. If the result of the logical expression is false, the iteration is ended. If the result of the logical expression is false even before the first iteration step, no iteration steps are executed.

This does not happen with LOOP AT itab [FROM idx1] [TO idx2]

  • If the value of idx2 is less than the value of idx1, no processing takes place.

 

I currently consider this deviation in the UNTIL Conditional Iteration a breach of contract. Just like in the case of SELECT FOR ALL ENTRIES with a empty internal table, the mental model is broken.

Summary

ABAP has been successful at eliminating off by 1 errors in loops with the pervasive LOOP statement. FOR .. THEN … UNTIL expressions give us the power to control the loop index. But by enforcing at least one iteration they break the mental model and yield endless loops.

Although the behavior is documented, I currently consider this a bug. There are more expressive way to specify an endless loop.

  • Can you think of a use case for this behavior?
  • Can anybody please create an extended syntax check rule for this special case?

Challenge Solution

  • An endless loop occurs.

The issue was observed on the SAP Cloud Platform, ABAP environment. After a trivial refactoring, the unit tests would abort with a runtime problem. Working with unit tests saved me, again.

Assigned Tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Peter Inotai
      Peter Inotai

      Thanks for sharing this.

      " I currently consider this a bug"

      Yes, I have the same feeling. Even if it's documented, it's an unexpected behaviour, so for me it's also a bug. Especially if FOR ... WHILE doesn't have this.

       

      Author's profile photo Sandra Rossi
      Sandra Rossi

      In other languages, WHILE and UNTIL have the same essential difference.

      • WHILE : the condition is tested before the block (so there can be 0 iteration)
      • UNTIL : the condition is tested after the block (so there’s a minimum of 1 iteration)

      So, it’s obviously not a bug, and personally I think it’s not error prone because it should be obvious to the vast majority of developers. Of course, it may happen that even developers who know that just do a mistake.

      I would say that it happens very often, whoever the developer is, whatever the statement is, that there are wrong assumptions, which are later discovered. For example:

      • SELECT does not order by primary key if there’s no explicit ORDER BY with the primary key.
      • CLEAR itab does not empty the internal table if it has a header line (select-options, function module parameter in category TABLES)
      • as you said: “SELECT FOR ALL ENTRIES with a empty internal table”
      • Etc.

      Some of them were so error prone that they were deprecated (header lines, ON CHANGE OF, etc.)

      Again, I personally consider UNTIL obvious.

      But your point is valid if UNTIL is misunderstood by many developers. Maybe via a poll/survey?

       

      Author's profile photo Jacques Nomssi Nzali
      Jacques Nomssi Nzali
      Blog Post Author

      Hello Sandra,

      I can think of a FOR WHILE as an expression enable WHILE clause, but FOR UNTIL has no corresponding statement in ABAP. I think the difference with other languages is the implicit auto-increment.

      Having a THEN clause makes it easier to spot the problem IMO,

      DATA(iota) = VALUE #( FOR idx = 0 THEN idx + 1 UNTIL idx = 0 ( idx ) ).

      so I will probably recommend to always write THEN in FOR .. UNTIL clauses.

      Thank you for the feedback,

      best regards,

      JNN

       

      Author's profile photo Michelle Crapo
      Michelle Crapo

      Poll?  I've never used it.  So now I know.

      Author's profile photo Paul Hardy
      Paul Hardy

      As has been said in other languages ( e.g. the BASIC I used in 1981 ) the problem is more obvious.

      LET monsters = 0.

      REPEAT.

      LET monsters = monsters + 1.

      UNTIL monsters = 0.

      Just by looking at it you can tell it will be an endless loop. A clear example of the "make bad code look bad" principle.

      As you said if you write the ABAP equivalent as

      FOR monsters = 0

      THEN monsters = monsters + 1

      UNTIL monsters = 0

      Then it looks as obvioulsy wrong as the BASIC equivalent.

      Some of the new ABAP constructs are anything but obvious and adoption will be slow to non-existnat if they (a) make the developer writing the ones head spin and (b) cannot be understood by anybody else coming along to change the code.

      The villain in the picece is the implicit (invisible) commands e.g. an invisible  THEN var + 1

      Every time you have something going on in the background the developer has no idea is happening, it all ends in tears. A logical database, may in rest in peace, was a fine example.

      SAP has a horrifying tendency to think if you make these hidden things optionalit will make the code shorter and easier tounderstand but I would disagree. I really do not like in the ABAP Restful Programming model all the implicit paramaters in method signatures which do not have to be declared, but then in the method you can write to them or read them and it looks like magic.

      This may sound obvious but if you go right out of your way to hide something from a developer, how is that developer going to know it is there? It's like hiding a rattlesnake in their briefcase and then being all surprised when all hell breaks loose at work when the developer arrives and opens their briefcase.

      Cheersy Cheers

      Paul