On Fri, 4 Aug 2017 23:19:13 +0000, Smith III, Phil (HPE Data Security (Voltage)) wrote:
>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"? ... > I begin every Rexx program with SIGNAL ON NOVALUE but code no handler. I consider reference to an undefined symbol a coding error, and fatal because there's really no way to recover. >... 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 >... A lot of that I'd do with SELECT and CALL. But partly I'm being compulsive about avoiding SIGNAL. And sometimes I force a terminal condition (such as NOVALUE) to get the procedure call trace. >* 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). -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
