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
