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

[Hans Hübner]

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