Am 20.02.2009 um 06:48 schrieb Hans Hübner:
On Fri, Feb 20, 2009 at 00:16, Vsevolod vseloved@gmail.com wrote:
Another thing worth mentioning, in my opinion, is that the old debug capabilities (*catch-errors-p* and *log-lisp-backtraces*) where indeed used (at least by me). So it's a pity not seeing them in the new release. Now the only way I found to get "under the hood" was with *break-on-signals*.
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot.
Thats actually not a feature. With *catch-errors-p* you ended up within an debugger too and it was actually a good thing that it was restricted to hunchentoot. *break-on-signals* is definitely the wrong tool to do that! Following the dev-tree for some time now I have just setup my own error handling using handler-bind in a custom dispatcher - similar to what Edi outlined in his answer. It should at least be documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone. The new hunchentoot is meant to be more customizable - it actually is, because of fantastic the merits of CL like handler-bind - It would have been nicer (from a library designer perspective) to have this integrated within the protocols though.
If you want to have bracktraces in your error log, you can easily install your own message logging function using the new :MESSAGE-LOGGER initarg of the ACCEPTOR class. We removed that part of Hunchentoot because it was really the last piece of unportable code that we had, and we did not use it ourselves anyway. Maybe someone can make a good cause for getting it back in. I'm not missing it.
Never used that - I prefer using just a lispworks debugger session.
ciao, Jochen
-- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg
Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83
mailto:info@crispylogics.com http://www.crispylogics.com