[hunchentoot-devel] Invoke-debugger

Peter Seibel peter at gigamonkeys.com
Sat Nov 14 16:56:58 UTC 2009


On Sat, Nov 14, 2009 at 2:46 AM, Edi Weitz <edi at agharta.de> wrote:

> But generally I think that CL has maybe the best condition
> system of all programming languages I know and we all don't use it
> enough.  In an ideal world, *break-on-signals* would be the right
> solution to this problem.  (And, yes, I've also used ignore-errors in
> places we I shouldn't have.)

I agree with the first two bits (best in the world, not used enough)
but I think I disagree with the latter (*break-on-signals* ought to be
the right solution). The thing that makes the condition system great
is that it separates the handling of conditions into not just two but
three parts. (signaling, handling, and restarting). It seems to me a
perfectly reasonable use of the condition system to signal a condition
somewhere down low, handle it up high (but still in code that was
called from Hunchentoot) and then restart in some application specific
way. However if the condition signaled matches the type spec in
*break-on-signals* that logic will be completely short circuited,
landing you in the debugger for a condition that was actually going to
be handled within the application code and would never have bothered
Hunchentoot at all.

*break-on-signals* could possibly be made to work if you could come up
with a type specifier that excluded all conditions of the sort I just
described but included all unhandled conditions. But even if you
could, that seems like a kludge to me--whether I want to end up in the
debugger is not a function of the condition's type--it's a function of
whether it's going to be handled before it percolates up to
Hunchentoot code to deal with.

-Peter


-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/




More information about the Tbnl-devel mailing list