On May 29, 2008, at 16:12, Richard M Kreuter wrote:
> | When setting ‘*break-on-signals*’, the user is encouraged to choose
> | the most restrictive specification that suffices. Setting
> | ‘*break-on-signals*’ effectively violates the modular handling of
> | condition signaling.
> So from my point of view, setting *BREAK-ON-SIGNALS* to something
> like T
> amounts to asking to be notified about everybody else's use of the
> condition system, even if the program calling the signaling code is
> prepared to handle the condition.
> But I think there's a way of using *BREAK-ON-SIGNALS* without running
> aground on incidental uses in library code:
> * first, define some base condition class for your application,
While not especially relevant to this use case, I'd like to point out
that another way to restrict *BREAK-ON-SIGNALS* for particular
debugging is to use a SATISFIES type specifier; e.g.
(satisfies ,(defun #:interestingp (c)
(eql (type-error-expected-type c)
I used this technique to break on errors of interest in a system much
like Hunchentoot as described (that is, in normal operation, errors
should be logged and the application returns to its event loop rather
than breaking or exiting), except that I didn't even want to break on
all propagated-to-the-event-loop errors.
On May 29, 2008, at 18:04, Travis Cross wrote:
> ... set *catch-errors-p* to nil. Setting it to nil simply turns off
> the default error handling in most of hunchentoot, allowing
> hunchentoot errors and unhandled errors from a user's hunchentoot
> dispatchers to reach the toplevel. Importantly, setting *catch-
> errors-p* to nil does *not* cause the lisp to break whenever a
> dispatcher throws a signal that gets caught before reaching
> hunchentoot code.
This seems to me to be a better approach than using *break-on-signals*.
A variation on this would be to, rather than not catching errors,
invoke the debugger explicitly; this would inhibit handlers enclosing
the event loop/catcher.
That is, with *catch-errors-p* as described, this handler will be
whereas it won't with the variation.
Whether that's desired would depend on the application. For mine, it
seems like the ideal thing would be "invoke debugger if there would
otherwise be a nonlocal exit out of (event-loop)", but I don't think
that's expressible in CL.
Kevin Reid <http://homepage.mac.com/kpreid/>