A similar problem occurs, when I am coding a subroutine (or function)
in C, PL/1, Pascal, whatever, and I am checking some conditions at the
start and processing should stop if the conditions aren't true, but immediate
return is no option, because some housekeeping has to be done at the end
of the function.

Example:

procedure do_something (parameters ...);

begin
  do_initialization;
  if not condition1 then
     /* don't continue */
else
     if not condition2 then
/* don't continue */
else
        if not condition3 then
/* don't continue */
else
           if not condition4 then
/* don't continue */
           else
              begin
                 do_processing
              end;
  do_housekeeping
end;

This looks awful because of the indentation.

For example, if implementing this logic in C, I could use goto,
of course. If I don't want to use goto, there is another solution,
involving a "dummy loop" and break:

void do_something (...)

{
  do_initialization ();
  do
  {
     /* one time dummy loop */

     if (! condition1)
        break;
     /* don't continue */

     if (! condition2)
        break;
     /* don't continue */

     if (! condition3)
        break;
     /* don't continue */

     if (! condition4)
        break;
     /* don't continue */

     do_processing ();
  }
  while (0);

  do_housekeeping ();
end;

This break, combined with the dummy loop,
works like a "goto forward", and IMO looks OK
and is maintainable.

In PL/1, you can use LEAVE for simple DO groups directly,
although you will get a warning, if you use it.

The warning is driven, AFAIK, by some improper use
(which occurs often in existing software), like:

DO I = 1 TO TABLE_COUNT;
   IF TAB(I) = 0 THEN DO;
      LEAVE;
   END;
   /* PROCESSING TAB (I) */
END;


often undected (LEAVE has no effect). Some companies
force the use of DO and END even on simple statements,
which leads to such errors. But that is (one or two)
another topics.

Kind regards

Bernd





Am 05.08.2017 um 01:19 schrieb Smith III, Phil (HPE Data Security (Voltage)):
Paul Gilmartin wrote:
Rexx has no GOTO.  "break" is LEAVE [control-variable] (and "continue is
ITERATE [control-variable]).  I never use Rexx SIGNAL other than to force
an error; its side effects are dreadful.
By "to force an error", do you mean "to say that something bad happened and end the program"? 
Because if so, I agree 100% (well, except for the slightly perverse "calculated goto" via "SIGNAL 
VALUE", which is useful in *very* specific, rare, heavily documented instances).

That is, I find this code much easier to read and maintain:

do <someloopcondition>
    ...
    if <statetest1 fails> signal BadCase1
    ...
    if <statetest2 fails> signal BadCase2
    ...
end
...
* And way down below somewhere:
BadCase1:
say "The very bad case#1 happened!"
exit 1

BadCase2:
say "The very bad case#2 happened!"
exit 2
(etc.)

than:
do <someloopcondition>
    ...
    maybeError=1
    if <statetest1 fails> leave
    ...
    maybeError=2
    if <statetest2 fails> signal BadCase2
    ...
    maybeError=0
end
if maybeError <> 0 then ...

or, perhaps more common:
do <someloopcondition>
    ...
    if <statetest1 fails> then do
       <handle the error, EXIT, etc.--often many lines>
    end
    ...
    if <statetest2 fails> then do
       <handle the error, EXIT, etc.--often many lines >
    end
    ...
end

The point is that the second and third cases are much harder to read and maintain. If 
you're disciplined about only using SIGNAL for this purpose, then seeing "Ah, he 
SIGNALs somewhere, he's done, that's not the mainline path" is quick and easy, 
allowing analysis of the mainline (and not incidentally grouping the errors in one place).

I don't want to get into a theological argument on a Friday afternoon, but having grown 
up with PL/I, the "No GOTOs noway never nohow" has always seemed overly rigid. 
Plus I'm currently living with code that uses the second technique above, and it's hell 
to debug (ok, in this case, it's much worse because it tends to set the maybeError *once* 
and then test five things, so you have to try to figure out which of the five really 
caused the error...just lazy programming).

...phsiii

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to