Re: [Sbcl-devel] Use of signals in PROBE-FILE

Richard M Kreuter wrote:
> "Hans Hübner" writes:
>
>> I am looking at this from a practical perspective, and I have a
>> concrete application in mind: Hunchentoot used to have a private
>> mechanism to control whether errors in HTTP handler functions are
>> caught and reported to the client or left unhandled so that they can
>> be debugged. We thought that Common Lisp already has such as
>> mechanism with *BREAK-ON-SIGNALS*, but using that showed to be harder
>> than expected because Hunchentoot itself uses PROBE-FILE, which always
>> signals (and catches) an error in SBCL.
>
> I'm not entirely clear what Hunchentoot's requirements are, but does
> *DEBUGGER-HOOK* do what you want? It would let your code decide what to
> do with otherwise-unhandled conditions, but not get involved in
> conditions that are already handled.
Hmmm. That sounds risky--what if the user is using *DEBUGGER-HOOK* for
their own purposes. You need at least to be sure that you observe the
old value of *DEBUGGER-HOOK* and call it (which probably goes without
saying) but even that depends on being sure that the user will set it
before you bind it. It seems to me that the normal condition handler
system gives you all the power you need to determine if a condition has
been (or will be) handled. (Recall the old, resignal and *then* handle
trick if you're worried about a condition-handler higher up on the stack
handling a condition you are considering handling. But I don't think
that applies in this case because all the user-code runs below a
well-known point on the call stack.)
-Peter
--
Peter Seibel : peter@...
A Billion Monkeys Can't be Wrong : http://www.gigamonkeys.com/blog/
Practical Common Lisp : http://www.gigamonkeys.com/book/
Coders at Work : http://www.codersatwork.com/