#12 error recovery

open
None
5
2004-05-02
2004-05-02
No

The ability not to lose the computation on error is
crucial for any serious task.
Therefore, we need to be able to recover from ALL errors.
There are two independent issues here:

1. "retry" restart on i/o, see
<https://sourceforge.net/mailarchive/message.php?msg_id=7607066>

2. "return-from" restart that will return the specified
values from the given function on the stack. we
already have that in interpreted functions, but we must
also have it in compiled functions.
<http://thread.gmane.org/gmane.lisp.clisp.devel/11448>

Discussion

  • Sam Steingold

    Sam Steingold - 2004-05-25

    Logged In: YES
    user_id=5735

    Another aspect is that use breaks must always be continuable.
    sometimes they are, sometimes they aren't.

     
  • Sam Steingold

    Sam Steingold - 2004-07-28

    Logged In: YES
    user_id=5735

    http://sourceforge.net/mailarchive/message.php?msg_id=8378179
    any function should be both restartable (with new arguments)
    and exitable (with specified return values) by default.
    therefore there should be 3 declarations
    PROCLAIM EXITABLE
    PROCLAIM NON-EXISTABLE
    PROCLAIM RESPECT-GLOBAL-EXITABLE

     
  • Jörg Höhle

    Jörg Höhle - 2004-11-01

    Logged In: YES
    user_id=377168

    I believe a UNIX SIGINT return to write() or read() does not
    specify what happened to the file. So how would you continue
    from such a thing? So I think it's just not possible, since
    the current data may be read/written twice or not at all if
    the operation is repeated.

    In AmigaCLISP, all interreupt-checking was synchronous, with
    the admitedly nice property that I could interrupt long
    computations any time, see where they were, then continue.
    The obvious drawback is that I/O was not interruptible. That
    is ok for one character at a time i/o, but not for
    read/write-sequence of large arrays.

     
  • Jörg Höhle

    Jörg Höhle - 2004-11-01

    Logged In: YES
    user_id=377168

    How useful would be "restart with new arguments"? I wonder
    because my assumption is that what's available on the
    STACK is the function object, not a symbol name for which a
    new fdefinition may have been entered while in the debug
    loop. Users may get upset by the restart utility invoking
    the old function when they just redefined it!

     
  • Sam Steingold

    Sam Steingold - 2004-11-01

    Logged In: YES
    user_id=5735

    if I get an error in my function SAVE-DATA,
    I want to be able to say "try again".
    i.e., unwind to the SAVE-DATA entry point
    (closing the stream which errored out)
    and start that same function on the same arguments.
    this would be a great advantage - I will not lose the data!

    as for function redefinition, we can check
    (eq FDEF (fdefinition (closure-name FDEF))
    and if it is NIL, offer 2 restarts:
    call old definition
    call new definition

     

Log in to post a comment.