johnm@spudge.UUCP (John Munsch) (02/01/90)
I have an AREXX script where I call a function that sometimes returns an error value. So, I put in: signal on error . . . error: <Error code> return to handle this error value. Great so far. But when I attempt to "return" from the error handler it treats the "return" as an exit. I read in the manual that this is what happens whenever you perform a "return" without having been "call"ed. So if I can't return to the point where the error occurred after having fixed up the problem, what kind of error recovery can I really have? John Munsch P.S. Every example of error trapping that I've found so far (including those that came with AREXX) just exit out at the end of the error routine.
new@udel.edu (Darren New) (02/03/90)
In article <10020@spudge.UUCP> johnm@spudge.UUCP (John Munsch) writes: >I have an AREXX script where I call a function that sometimes returns an error >value. So, I put in: >signal on error >error: > <Error code> > return >to handle this error value. Great so far. But when I attempt to "return" >from the error handler it treats the "return" as an exit. I think that the signal instruction is more a goto than a call. To solve this, you can do the following. Say your real function is called XYZZY and if it returns an error you want 'PLOVER' returned from the call. Recode all the calls to XYZZY to be calls to XYZZY$ and do the following: blah = XYZZY$(foo) ... ... ... blah2 = XYZZY$(foo2) ... ... ... XYZZY$: procedure parse arg y2 signal on error retval = XYZZY(y2) signal off error return retval error: return 'PLOVER' This, I should thing, will do the trick. Messy but effective. -- Darren