... some of the indentation in the first example,
which was already awful, has been further damaged
by my eMail program :-)
Am 05.08.2017 um 10:44 schrieb Bernd Oppolzer:
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
