Re: [Oorexx-devel] Non-ANSI behavior of SIGNAL ON with internal calls.

[David A. <da...@us...>]

I think the goal of ANSI compatibility is a great thing, but in some cases 
the reasoning behind the standard breaks down in an object-oriented world. 
This is obvious because classic Rexx is strictly procedural.

I would hate to see ooRexx held back because of strict ANSI compatibility 
requirements. And I believe that changing the current ooRexx behavior to 
be more ANSI compatible in this case is not wise and has no real benefit 
to the user. The fact that implementing the ANSI behavior would deprive 
the user of diagnostic information is by itself enough reason not to 
restrict ooRexx to ANSI behavior. But removing the ability to implement a 
proper oo CATCH mechanism is the real clincher.

The ANSI standard is not the be-all or end-all of standards. Where it 
applies to and enhances ooRexx I am all for it. But conforming to the 
standard when there is no direct benefit to the ooRexx user and places 
impediments to implementing oo features into ooRexx is enough reason to 
ignore the standard where it makes sense to do so.

Thanks,
W. David Ashley
IBM Systems and Technology Group Lab Services
Open Object Rexx Team
Office Phone: 512-838-0609 T/L 678-0609
Mobile Phone: 512-289-7506




"Rick McGuire" <obj...@gm...> 
Sent by: oor...@li...
05/10/07 11:52 AM
Please respond to
Open Object Rexx Developer Mailing List 
<oor...@li...>


To
"Open Object Rexx Developer Mailing List" 
<oor...@li...>
cc

Subject
Re: [Oorexx-devel] Non-ANSI behavior of SIGNAL ON with internal calls.






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




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Oorexx-devel mailing list
Oor...@li...
https://lists.sourceforge.net/lists/listinfo/oorexx-devel