On Sat, Nov 14, 2009 at 5:56 PM, Peter Seibel peter@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.