After opening a RFE (https://sourceforge.net/p/oorexx/feature-requests/852/), Erich pointed out that
the ::OPTIONS condition CONDITION|SYNTAX does not propagate non-SYNTAX conditions and hence closed
the RFE as rejected, which is appropriate.
As the ability to define condition handlers at the top of a call chain/tree to optionally intercept
and handle conditions raised in any of the called routines/methods can be important/very helpful for
certain use cases, I would like to open a different RFE for that purpose. But before doing so, I
would like to present the idea and ask for feedback:
A programmer may use the ooRexx RAISE keyword instruction to raise all these
plus the condition
"USER usercondition".
A SYNTAX condition will propagate up the call chain so that it can be
trapped in these.
Some conditions like "USER usercondition" cause a RETURN from the current
executable and, if not
trapped in the caller, will not cause any runtime error to be created nor
would that condition
get propagated.
If not trapped, others, like the HALT condition, will be turned into a
SYNTAX condition (in this
case, syntax error 4) that can be trapped by executables up the call chain.
The condition names carry the semantics of what condition is present. Those
conditions regarded
as trapped will be turned into SYNTAX conditions if they do not get trapped.
---
There are situations for Rexx programmers where it would be desirable to
become able to trap the
original conditions up the call chain. This would create "central"
trap/condition handlers in an
executable up in the call chain. One use case for this was the case of HALT,
where the desire
was to become able to handle that condition at the top of the call chain. To
achieve this, one
would have to create HALT trap/condition handlers in all executables and do
a raise propagate,
such that the HALT condition arrives up the call chain intact. In the case
of HALT, knowing that
if the HALT condition is not handled, it gets changed to a SYNTAX 4
condition and then
propagated such that any of the callers in a call chain can trap/handle it.
The behavior to turn unhandled/untrapped conditions to SYNTAX conditions
that get propagated is
not applied to all conditions. Notably, raising the "USER usercondition",
but not
trapping/handling it in the immediate caller does not turn it into a syntax
condition (which
works as designed). If there is a need to propagate user conditions, then it
is mandatory to
manually define trap/condition handlers and then use raise propagate in /all
/routines/methods
of the call chain, which is quite cumbersome. This may affect ooRexx
frameworks and complex
ooRexx programs.
If there were an option to denote conditions that should be propagated like
SYNTAX conditions,
it would become possible to define trap/condition handlers "centrally" (in
any of the
routines/methods up the call chain) and use the original condition names
(which convey the
meaning of the raised condition).
To indicate which condition should be propagated in this manner, one could
perhaps allow for the
subkeyword PROPAGATE in addition to SYNTAX and CONDITION, e.g., "::OPTIONS
condition
SYNTAX|CONDITION|PROPAGATE", where 'condition' would be any of the condition
names that can be
supplied to the RAISE keyword instruction plus 'ALL' to mean all conditions.
So the questions at this point would be:
* Would that be seen as a useful/helpful addition for Rexx programmers?
---rony
On 17.03.2025 15:51, Rony G. Flatscher wrote:
On 17.03.2025 09:37, Till Winkler via Oorexx-devel wrote:
I'm trying to catch user interrupts (typically triggered by: CTRL + C).
While I managed to gain a working example (see attached), I was
wondering if there might be a better way to deal with it?
In particular, I would like to avoid the repetition of labels (in the
example: “propagate:”) and it would be nice to collect all labels (in
the example: “propagate:” and “halt:”) in a single place and even in a
separate file.
Hope someone has an idea for this!?
Rick has pointed out that a HALT condition gets turned into a syntax 4.1 condition, which the
interpreter propagates and, as such, can be intercepted by executables up in the call chain.
However, this means that a programmer needs to know about this conversion mechanism, which is not
necessarily obvious as a proper "HALT" condition already exists in ooRexx for this particular
condition.
The current ::OPTIONS directive allows for a) automatic propagation of conditions and b)
determining how the propagation should occur, i.e., create a syntax condition or propagate the
condition itself.
Currently, the following conditions can be denoted in the 'options' directive:
• ALL (encompasses ERROR, FAILURE, LOSTDIGITS, NOSTRING, NOTREADY, NOVALUE, cf 'options'
directive, rexxref.pdf, p. 101)
• ERROR
• FAILURE
• LOSTDIGITS
• NOSTRING
• NOTREADY
• NOVALUE
So defining "::options novalue condition" at the end of a program ("package") would activate and
propagate NOVALUE conditions up the call chain, where defining "::options novalue syntax" would
create a syntax condition instead that gets propagated (maybe a syntax error like 98.986 which may
not be obvious).
Currently, however, the following conditions cannot be stated on the
'::options' directive:
• HALT
• USER
• NOMETHOD
• SYNTAX (for orthogonality)
If it was possible to state "::options HALT CONDITION", then the "HALT" condition could be trapped
in trap handlers anywhere up in the call chain as HALT condition rather than needing to know about
the translation to a SYNTAX 4.1 and then intercepting that particular syntax condition.
To denote user-defined conditions would be especially useful for complex ooRexx frameworks and
ooRexx applications if user conditions can be propagated by the interpreter using the 'options'
directive (e.g. "::options USER CONDITION" which would propagate all user conditions) such that a
central user condition handling becomes possible somewhere up in the call chain.
Allowing the NOMETHOD condition to be propagated would allow for intercepting and handling it up
in the call chain, allowing an "unknown" like handling of such situations, potentially even
outside of classes, if need be.
Also, allowing SYNTAX to be denoted may be helpful because then all conditions can be declared in
the 'options' directive, and there would be no need to memorize exceptions (increasing the
cognitive load). In the syntax condition case, the subkeyword CONDITION would have no effect as a
syntax condition would be propagated as a syntax condition (as would the subkeyword SYNTAX).
Any thoughts?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
