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

[Hans Hübner]

Andrei,

the error page that you have sent was generated by Apache, not Hunchentoot.

-Hans

On Wed, Jul 25, 2012 at 12:46 AM, Andrei Stebakov <lispercat at gmail.com> wrote:
> 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
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel