> He had a Rexx program in which he handled error conditions > in nested CALLs, avoiding status variables, by > SIGNAL Top_of_main_loop.
SIGNAL is not GOTO. See https colon //www.rexxla.org/Newsletter/9812safe.html for my perspective on SIGNAL. As you can see in https colon //www.rexxla.org/Newsletter/9901safe.html, I do eschew SIGNAL for anything but error handling, but GOTO, at least in Algol-like languages, is much better behaved. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, March 24, 2020 11:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Does anybody remember CLIST? On Tue, 24 Mar 2020 21:02:57 +0800, David Crayford wrote: >On 2020-03-21 11:45 PM, Paul Gilmartin wrote: >> o Symbols EXPOSEd from external scopes can't be used as targets >> of ITERATE and LEAVE. (I eschew GOTO; SIGNAL is worse,) >If you eschew goto how do you deal with error handling and cleanup using >a language which >doesn't support exceptions, finalization or RAII? I find these kind of >blanket rules to lead to bad code >with deep nesting and useless status variables. > Yah, I know. But, war story: A co-worker approached me for help. He had a Rexx program in which he handled error conditions in nested CALLs, avoiding status variables, by SIGNAL Top_of_main_loop. He had tested it with a small data set, perhaps even with error injection. But in production on a large data set, CALL/RETURN stack overflowed. My envisioned longITERATE and longLEAVE woild properly clean up the stack while leaving the enclosing DO intact, having no enticement to cavatappi coding. And there should be an option to repair error condition and proceed. -- gil ---------------------------------------------------------------------- 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
