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 [email protected] with the message: INFO IBM-MAIN
