[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Fri, 28 Sep 1990 12:43 EDT
From: firstname.lastname@example.org (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
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.)