[hunchentoot-devel] *show-lisp-errors-p* ignored?

[Andrei Stebakov]

Maybe I am doing something wrong, but I subclassed
acceptor-status-message and it's called and the custom-error-page is
called, but in the final page I still see output like:

Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, info at domain.com and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.
More information about this error may be available in the server error log.
Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.19 with Suhosin-Patch
mod_ssl/2.2.8 OpenSSL/0.9.8g Server at www.yourspecialtee.com Port 80

I wonder what's missing?

On Tue, Jul 24, 2012 at 2:42 PM, Hans Hübner <hans.huebner at gmail.com> wrote:
> Andrei,
>
> I understand that your problem is solved now.  Let me just point out
> that def-http-return-code is an internal macro that is not part of
> Hunchentoot's API and not mentioned in the documentation.  I am not
> entirely opposed to making it part of the API if that'd be useful, and
> maybe you have a valid use case.  Thus, if that would be easier than
> subclassing the acceptor class, maybe you can come up with a patch.
>
> -Hans
>
> On Tue, Jul 24, 2012 at 8:01 PM, Andrei Stebakov <lispercat at gmail.com> wrote:
>> Certainly, I was just wondering about the philosophy of the new error
>> handing mechanism.
>> I thought if it was based on custom http return codes defined by
>> def-http-return-code than the users would define their own using the
>> same mechanism.
>>
>> Thank you,
>> Andrei
>>
>> On Tue, Jul 24, 2012 at 11:41 AM, Hans Hübner <hans.huebner at gmail.com> wrote:
>>> Andrei,
>>>
>>> you are welcome to send patches if you feel that Hunchentoot lacks
>>> functionality that you need. Please use github pull requests. Do not forget
>>> to include documentation updates if you want to change the public API.
>>>
>>> Thanks,
>>> Hans
>>>
>>> Am 24.07.2012 16:32 schrieb "Andrei Stebakov" <lispercat at gmail.com>:
>>>
>>>> As I understand the whole acceptor-status-message has to be overloaded?
>>>> The user is discourage from defining their own (def-http-return-code
>>>> +some-user-code+ 777 "Some user message")?
>>>>
>>>> Andrei
>>>>
>>>> On Mon, Jul 23, 2012 at 4:19 PM, Hans Hübner <hans.huebner at gmail.com>
>>>> wrote:
>>>> > Andrei,
>>>> >
>>>> > you can implement a method for HUNCHENTOOT:ACCEPTOR-STATUS-MESSAGE
>>>> > (http://weitz.de/hunchentoot/#acceptor-status-message) specialized for
>>>> > your own acceptor class if the cooked message and the templating
>>>> > mechanism are insufficient for your needs.
>>>> >
>>>> > -Hans
>>>> >
>>>> > On Mon, Jul 23, 2012 at 10:08 PM, Andrei Stebakov <lispercat at gmail.com>
>>>> > wrote:
>>>> >> Thank you, Hans for the prompt response.
>>>> >> On the related subject, it used to be *http-error-handler* variable
>>>> >> that I set to a function where I handled all errors related to my own
>>>> >> run-time environment, (not hunchentoot related).
>>>> >> Basically before, I saved the error message in the hunchentoot
>>>> >> session-value and triggered (error ...) function.
>>>> >> My handler specified by *http-error-handler* would be called so I
>>>> >> generated an error page printing the saved message from the
>>>> >> session-value.
>>>> >> Now that the *http-error-handler* variable has been deprecated, what
>>>> >> is the best place I could put my own error page generation code?
>>>> >>
>>>> >> Thank you,
>>>> >> Andrei
>>>> >>
>>>> >> On Sat, Jul 14, 2012 at 2:20 AM, Hans Hübner <hans.huebner at gmail.com>
>>>> >> wrote:
>>>> >>> Andrei,
>>>> >>>
>>>> >>> the *show-lisp-errors-p* and *show-lisp-backtraces-p* are ignored if
>>>> >>> the acceptor has been instantiated with an error template directory,
>>>> >>> which is the default.  You need to use :error-template-directory nil
>>>> >>> when instantiating the acceptor to use the cooked messaging feature,
>>>> >>> which looks at these variable settings.
>>>> >>>
>>>> >>> http://weitz.de/hunchentoot/#*show-lisp-errors-p*
>>>> >>>
>>>> >>> -Hans
>>>> >>>
>>>> >>> On Sat, Jul 14, 2012 at 6:24 AM, Andrei Stebakov <lispercat at gmail.com>
>>>> >>> wrote:
>>>> >>>> Hi
>>>> >>>>
>>>> >>>> I got following variables set before running Hunchentoot
>>>> >>>>
>>>> >>>>   (setf hunchentoot:*catch-errors-p* t)
>>>> >>>>   (setf hunchentoot:*show-lisp-errors-p* nil)
>>>> >>>>   (setf hunchentoot:*log-lisp-errors-p* t)
>>>> >>>>   (setf hunchentoot:*show-lisp-backtraces-p* nil)
>>>> >>>>
>>>> >>>> For some reason, when an error happens (or when I explicitly call
>>>> >>>> (error "test")), I still see the whole lisp backtrace printed in the
>>>> >>>> browser.
>>>> >>>> How do I fix this? It looks like make-cooked-message isn't called for
>>>> >>>> every request as well.
>>>> >>>>
>>>> >>>> Thank you,
>>>> >>>> Andrei
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> tbnl-devel site list
>>>> >>>> tbnl-devel at common-lisp.net
>>>> >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> tbnl-devel site list
>>>> >>> tbnl-devel at common-lisp.net
>>>> >>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> >>
>>>> >> _______________________________________________
>>>> >> tbnl-devel site list
>>>> >> tbnl-devel at common-lisp.net
>>>> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>> >
>>>> > _______________________________________________
>>>> > tbnl-devel site list
>>>> > tbnl-devel at common-lisp.net
>>>> > http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>
>>>> _______________________________________________
>>>> tbnl-devel site list
>>>> tbnl-devel at common-lisp.net
>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel