From: Rick M. <obj...@gm...> - 2007-05-10 16:52:05
|
One more point I should note. The current ooRexx behavior will mesh quite nicely with the goal of adding NetRexx style "catch" capability to the block instructions. With catch, it would be certainly wrong to terminate the program without allowing the error to be processed. Adding this would mean that there would be two different behaviors for syntax errors depending on whether SIGNAL ON or CATCH is used for the trap. Rick On 5/10/07, Rick McGuire <obj...@gm...> wrote: > > There's been a bit of discussion recently between Ian Collier and I on > comp.lang.rexx about the behavior of SIGNAL ON SYNTAX in ooRexx. Here's a > simple program that demonstrates the situation: > > signal on syntax > restart: > call test > exit > syntax: say "Syntax error on line" sigl":" errortext(rc) > signal restart > test: return 77/0 > > On ooRexx, the SIGNAL ON SYNTAX trap will trigger twice. On the mainframe > Classic Rexx, it will only trigger once. > > Here's the sequence of events on ooRexx: > > 1) The Trap triggers. The SYNTAX trap at the current level is turned > off. > 2) The second syntax error occurs. The current call level is terminated, > and because the SIGNAL ON SYNTAX trap is still active at the original call > level, this trap triggers, from the point of the "call test" instruction. > The SYNTAX trap is now disabled at this level. > 3) The third time the syntax error occurs, there's no active trap any > more, and the program is terminated. > > On the mainframe Rexx, step 1 is the same, but the program EXITs > immediately on step 2 because there's no trap in place at the current > level. This is actually the behavior specified by the ANSI standard. > > Note that things behave differently if there is a call to an external rexx > routine involved: > > /* PROGRAM1 */ > signal on syntax > call program2 > exit > syntax: say "Syntax error on line" sigl":" errortext(rc) > exit > > > /* PROGRAM2 */ > signal on syntax > restart: > return 77/0 > syntax: say "Syntax error on line" sigl":" errortext(rc) > signal restart > > > For Classic Rexx, the SYNTAX trap in PROGRAM1 will see the generic Invalid > call to routine error (Error 40) as a result of the error calling PROGRAM1. > For ooRexx, the error information will reflect the original error in > PROGRAM2, including the full error traceback. Note that method calls and > external routine calls are identical situations. > > For case 2, I certainly find the ooRexx handling to be much nicer than the > Classic Rexx handling...it really bothers me to throw away information that > would be useful for problem determination. > > For case 1, it's certainly possible to have the syntax error bypass any > internal call levels and terminate at last to the original top-level call ( > i.e., a level that would be terminated by EXIT). On the other hand, it > somehow feels wrong to me that the original calling routine does not get the > opportunity to handle an error because a called internal routine has turned > the trap off at its level, either explicitly or implicitly. > > The original intent of turning off the trap when triggered was to avoid > infinite recursion errors on the traps. An infinite error cannot occur in > this case, as each time the trap triggers, it would end up unwinding one > more level of the call stack and would eventually unwind all the way. Also, > that original behavior dates back to the days when there was just a single > option for the trap target, the label SYNTAX:. Now that you can have > separately named signal handlers, it feels even more wrong to me that the > caller's trap would be bypassed. > > Anyway, I'm looking for opinions on what should be done here: > > 1) Leave it the way it is and accept that it's non-ANSI. > 2) Fix it so that an unhandled SYNTAX error in an internal routine will > cause the equivalent of an EXIT from that point. > 3) Something else ????? > > Rick > > > > > |