[hunchentoot-devel] Invoke-debugger

Edi Weitz edi at agharta.de
Sun Nov 15 11:58:32 UTC 2009


On Sat, Nov 14, 2009 at 5:56 PM, Peter Seibel <peter at gigamonkeys.com> wrote:

> 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.

Yes, I agree.  I was probably a bit too over-enthusiastic with the
third bit... :)

Still, I only have a finite amount of time.  The Hunchentoot-specific
error handling was thrown out with the 1.0.0 release and if we add
something similar back in, I want it to be a reasonable, working,
flexible, and well-documented solution.  That takes time, and I'll do
it when I have that time, this being not a priority for me right now.

Thanks,
Edi.




More information about the Tbnl-devel mailing list