Exit completely while in error traps? - Hewlett Packard

This is a discussion on Exit completely while in error traps? - Hewlett Packard ; Is there a sysRPL command that will exit completely from subroutines all the way to the stack, regardless of whether or not they are contained in multiple error traps? Kind of like a "super KILL"? I ask because I have ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Exit completely while in error traps?

  1. Exit completely while in error traps?

    Is there a sysRPL command that will exit completely from subroutines
    all the way to the stack, regardless of whether or not they are
    contained in multiple error traps? Kind of like a "super KILL"?

    I ask because I have a couple of communication commands that are
    generally buried under several error checks from different locations
    and while I could add in checks to test if the cancel key were pressed
    all the way through, I don't want to mess with them as it could break
    the instrument communication somehow and I don't have ready access to
    all 20-30 instruments to test. With some of them, they can stream
    data at high speed and there is occasionally trouble interrupting the
    loops to exit all the way.

    TW

  2. Re: Exit completely while in error traps?

    On Sun, 23 Dec 2007 10:07:30 -0600, TW wrote:

    > Is there a sysRPL command that will exit completely from subroutines
    > all the way to the stack, regardless of whether or not they are
    > contained in multiple error traps? Kind of like a "super KILL"?


    Doesn't KILL ( #123 DO#EXIT ) already do that?

    > I ask because I have a couple of communication commands that are
    > generally buried under several error checks from different locations
    > and while I could add in checks to test if the cancel key were pressed
    > all the way through, I don't want to mess with them as it could break
    > the instrument communication somehow and I don't have ready access to
    > all 20-30 instruments to test. With some of them, they can stream
    > data at high speed and there is occasionally trouble interrupting the
    > loops to exit all the way.


    Do you have traps which refuse to exit loops?

    Or which disable interrupts, ignoring CANCEL anyway?

    For programs which do not do either of the above
    it's possible to design a multi-level EXIT command;
    the following illustrates this for UserRPL only:

    Easy way (should it work for SysRPL too?):
    http://groups.google.com/group/comp....91c5df355bafde

    Hard way (and only for UserRPL programs):
    http://groups.google.com/group/comp....562173221472cb

    [r->] [OFF]

  3. Re: Exit completely while in error traps?

    On Sun, 23 Dec 2007 19:13:15 -0600:

    > Doesn't KILL ( #123 DO#EXIT ) already do that?


    #DFF DO#EXIT is another interesting one
    (it's what kills programs when "control alarms" come due,
    but stays within any current HALTed environment)

    #13E DO#EXIT is equivalent to CONT
    (and KILL is just "Super CONT"

    [r->] [OFF]

  4. Re: Exit completely while in error traps?

    > Doesn't KILL ( #123 DO#EXIT ) already do that?

    Not what I am thinking. I will explain with a little bit of code.

    xTEST
    ::
    ERRSET
    ID INNER
    ERRTRAP
    ::
    ( error testing )
    ID TEST ( reloop again always, i'd like it NOT to if during the
    inner loop it was cancelled and not some other error )
    ;
    ;

    xINNER
    ::
    ERRSET
    ::
    ( lots of communication stuff, if cancel pressed to stop, it
    would exit ALL the way out )
    ;
    ERRTRAP
    ::
    ( do some stuff )
    xKILL ( kill here doesn't exit cleanly. . . i'd like to exit all
    the way out )
    ;
    ;

    Now I could individually make all of these error traps test for
    cancel being pressed, but I was hoping there was a simpler way then
    editing them all and then retesting with the instruments to verify
    that nothing else was messed up. Some of them have some rather
    unfortunate timing issues that can make the difference between working
    perfectly and failing a single command that slows it a fraction of a
    second too much . . . :-(

    TW

  5. Re: Exit completely while in error traps?

    On Mon, 24 Dec 2007 13:50:00 -0600, TW:

    > ID TEST ( reloop again always, i'd like it NOT to if during the
    > inner loop it was cancelled and not some other error )


    How about a COLA?

    E.g. \<< X \>> 'X' STO X @ Out of memory (return stack), in due course

    > ERRTRAP
    > ::
    > ( do some stuff )
    > xKILL ( kill here doesn't exit cleanly. . . i'd like to exit all
    > the way out )


    What is meant by "doesn't exit cleanly"?

    What if xKILL is replaced by #123 DO#EXIT (or #DFF)

    One can also set FALSE/TRUE within the ERRSET/ERRTRAP,
    and then CASE afterwards (if it makes any difference).

    > Now I could individually make all of these error traps test for
    > cancel being pressed, but I was hoping there was a simpler way then
    > editing them all and then retesting with the instruments to verify
    > that nothing else was messed up. Some of them have some rather
    > unfortunate timing issues that can make the difference between working
    > perfectly and failing a single command that slows it a fraction of a
    > second too much . . . :-(


    Why call everything via IDs? Maybe first store in LAMs? Library?

    Is Raymond listening? (always has better ideas

    There are still a few hours left to ask Santa
    to drop a program down your chimney
    (preferably already on an SD card

    Season's Greetings

  6. Re: Exit completely while in error traps?

    > How about a COLA?

    I've played with return statck stuff. The issue is that the program
    might be called from a single route, or is the 5th subroutine down
    from the main runstream. It all depends on where it is being used.

    > What is meant by "doesn't exit cleanly"?


    It gets caught by error traps in previous subroutines. Like I said, I
    could probably modify all of them to make it detect cancel being
    pressed, but I'd like to avoid that if it isn't needed.

    > Why call everything via IDs? *Maybe first store in LAMs? *Library?


    They aren't. That was just some quick pseudo code to illustrate.

    Is there a command or method that will exit completely out of any
    running subroutines, ignoring error traps that may be catching errors,
    and works regardless of the presence of any number of error traps or
    previous runstreams?

    TW

  7. Re: Exit completely while in error traps?

    Hello,

    first some pre-requisites:

    There are two related RPL words:
    ERRSET and ERRTRAP

    These two words are always used together like this:
    ERRSET
    Code
    ERRTRAP
    ErrorHandler

    The actual code for the above construct doesn't need to be in the same file,
    though.

    An error generated between ERRSET and ERRTRAP will always
    cause the system to jump to the associated ERRTRAP code.

    In other words: Once you activate the TRAP, an error will be caught by it.

    See RPLMAN.doc for more details on ERRSET, ERRTRAP and the protection word !

    A customized and nested ERRTRAP is shown below:


    DEFINE #ExitAll MINUSONE

    :: CK0
    ERRSET
    ::
    * #ExitAll DO#EXIT

    ERRSET
    ::

    * #ExitAll DO#EXIT

    ERRSET
    ::
    #ExitAll DO#EXIT
    * Or alternatively: #ExitAll ERRORSTO ERRJMP, which is nearly the same.
    ;

    ERRTRAP
    :: ERROR@ #ExitAll #= case ERRJMP ( *Pass err to nxt lvl* )
    ERRBEEP TWO ( *Handle err at this lvl* )
    ;

    ;

    ERRTRAP
    :: ERROR@ #ExitAll #= case ERRJMP ( *Pass err to nxt lvl* )
    ERRBEEP ONE ( *Handle err at this lvl* )
    ;

    ;

    ERRTRAP
    ::
    * ERROR@ #ExitAll #= case ERRJMP
    ERRBEEP ZERO
    ;

    ;


    '#ExitAll DO#EXIT' could be inserted at any level,
    as indicated by the commented-out implementations of it.
    If the error-trapping code is implemented like in the example above,
    the ExitAll signal will always cause the program control to be passed
    to a certain program (or more exactly, error handling) level,
    in the example to level zero.
    The program will always return ZERO, regardless at which level
    '#ExitAll DO#EXIT' was invoked.

    This is a clean method, and enables the main program to actually
    handle errors which were generated on any sub-level.

    As stated above, I suspect you don't want to 'exit all the way out',
    but want your main program to retain control of what's happening.


    Forget COLA and the related words in this context.
    Apart from that, your illustrative code showed a type
    of loop construction which is rather ineffective.
    Calling TEST from within TEST is not as performant
    as defining a 'real' loop (DO..UNTIL, or suitable),
    except if you want to use some kind of recursion.


    HTH, and have some nice Xmas days

    Raymond


    "TW" schrieb im Newsbeitrag
    news:5ff62b58-7be4-4251-8b42-2a28d93488a6@i29g2000prf.googlegroups.com...
    > How about a COLA?


    I've played with return statck stuff. The issue is that the program
    might be called from a single route, or is the 5th subroutine down
    from the main runstream. It all depends on where it is being used.

    > What is meant by "doesn't exit cleanly"?


    It gets caught by error traps in previous subroutines. Like I said, I
    could probably modify all of them to make it detect cancel being
    pressed, but I'd like to avoid that if it isn't needed.

    > Why call everything via IDs? Maybe first store in LAMs? Library?


    They aren't. That was just some quick pseudo code to illustrate.

    Is there a command or method that will exit completely out of any
    running subroutines, ignoring error traps that may be catching errors,
    and works regardless of the presence of any number of error traps or
    previous runstreams?

    TW



  8. Re: Exit completely while in error traps?

    On Mon, 24 Dec 2007 17:43:32 -0800 (PST), TW
    wrote:

    ON-C or Paper Clip reset...

    >Is there a command or method that will exit completely out of any
    >running subroutines, ignoring error traps that may be catching errors,
    >and works regardless of the presence of any number of error traps or
    >previous runstreams?
    >
    >TW



  9. Re: Exit completely while in error traps?

    On Dec 23, 9:13 pm, "John H Meyers" wrote:
    > On Sun, 23 Dec 2007 10:07:30 -0600, TW wrote:
    > > Is there a sysRPL command that will exit completely from subroutines
    > > all the way to the stack, regardless of whether or not they are
    > > contained in multiple error traps? Kind of like a "super KILL"?

    >
    > Doesn't KILL ( #123 DO#EXIT ) already do that?
    >
    > > I ask because I have a couple of communication commands that are
    > > generally buried under several error checks from different locations
    > > and while I could add in checks to test if the cancel key were pressed
    > > all the way through, I don't want to mess with them as it could break
    > > the instrument communication somehow and I don't have ready access to
    > > all 20-30 instruments to test. With some of them, they can stream
    > > data at high speed and there is occasionally trouble interrupting the
    > > loops to exit all the way.

    >
    > Do you have traps which refuse to exit loops?
    >
    > Or which disable interrupts, ignoring CANCEL anyway?
    >
    > For programs which do not do either of the above
    > it's possible to design a multi-level EXIT command;
    > the following illustrates this for UserRPL only:
    >
    > Easy way (should it work for SysRPL too?):http://groups.google.com/group/comp....91c5df355bafde
    >
    > Hard way (and only for UserRPL programs):http://groups.google.com/group/comp....562173221472cb
    >
    > [r->] [OFF]


    How about a UserRPL program to do KILL and then Run another program.

    I use the scheme below, though I've never been very happy with it. I
    wonder if there is a more elegant way to do it.

    \<< \-> a
    \<< DATE TIME .00007 HMS+
    \<< DELALARM EVAL
    \>> 3. \->LIST STOALARM CLEAR a CLLCD KILL
    \>>
    \>>
    'KLL' STO

    Then if I want to KILL and then run object PROMENU I run
    \<<
    \<< PROMENU
    \>> KLL
    \>>

    Luis

+ Reply to Thread