Condition handling

[KMP@STONY-BROOK.SCRC.Symbolics.COM (Kent M Pitman)]

    Date: Fri, 28 Sep 1990 12:43 EDT
    From: alames@sandia.gov (2814 AMES, ARLO L.)
    Subject: Condition handling
    To: slug@Warbucks.AI.SRI.COM (slug)

    I need a bit of help with condition handling.  I have a routine that
    occasionally divides by zero, getting a CLI::SIGNAL-DOUBLE-FLOAT-TRAP.

The actual condition signalled is probably SYS:FLOAT-DIVIDE-BY-ZERO.
You can find this out by going into the debugger and stepping back (with c-P)
to the DBG:SIGNAL-CONDITION frame and look at the SELF argument.
You can call TYPE-OF on that argument to find out its type.
You can use Show Flavor Components to see what more abstract flavors contribute
to the instantiated flavor.

    The <RESUME> response, returning infinity, is appropriate here. 

In trying to determine how to write the handler, you can find out what
proceed options are available at that point by doing
 (DBG:PROCEED-TYPES condition)
where condition is the condition you got from above.

    Such division happens OFTEN, and I'd like to use something like CONDITION-BIND
    and SYS:PROCEED to simply take the resume response.  Any examples of how
    to do it?

(DEFUN TRY-NON-TRAP-RESULT (CONDITION)
  (WHEN (DBG:PROCEED-TYPE-P CONDITION :USE-NON-TRAP-RESULT)
    (DBG:PROCEED CONDITION :USE-NON-TRAP-RESULT)))

(CONDITION-BIND ((SYS:FLOAT-DIVIDE-BY-ZERO #'TRY-NON-TRAP-RESULT))
  (/ 1.0d0 0.0d0))

Note that if there is no such proceed option, it will not try to
proceed, and will instead return NIL.   In that case, other handlers
will be tried, and you may still end up in the debugger.

Note also that the effect of the CONDITION-BIND is dynamic, so you
should bind it in the outermost function that seems conceptually
reasonable for your application in order to avoid doing the
CONDITION-BIND repeatedly on an inner loop.  (On the other hand, you
should not bind it so far out that it will affect computations which
you do not believe are appropriate to handle in this way.)