Oh, I got it, so every hunchentoot handler should have its own error handlng procedure. I wonder if it's going to interfere with the internals of process-request function when it does the logging and other stuff? Still it would be nice to have one hook handler for all of my request handlers so I don't have to write the handler-case block for all of them. Also from my own code how do I use the get-backtrace function?


Thank you,
Andrew

On 4/8/07, Andrei Stebakov < lispercat@gmail.com> wrote:
Right, but I'd like to have a handler if something wrong goes in request processing, when the user sees the backtrace on the screen.

Andrew


On 4/8/07, Yoni Rabkin Katzenell <yoni-r@actcom.com> wrote:
"Andrei Stebakov" <lispercat@gmail.com> writes:

> What's the best to add my own error handler? I see there is some processing
> based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside
> process-request function, but it doesn't allow to add a user handler of the
> error (or I just didn't find it). Let's say I don't want a user to see the
> error (only some nice reassuring message :)) and I want to be notified by an
> email with the backtrace. Should I go and modify the body of the
> process-request function (which I'll need to merge with every new release of
> HT) or is there a way to add my own handler outside of the Hunchentoot code?

I've generally found it enough to define error handlers just like I
usually do in CL:

(defun foo ()
  "Display the foo page"
    (handler-case
        (... faulty code which might produce some error ...)
      (error () (display-a-nice-error-message))))

--
   "Cut your own wood and it will warm you twice"
_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel