On Sat, Nov 14, 2009 at 2:46 AM, Edi Weitz edi@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