By default, the debugger is not entered, but the error info appears in /tmp/hunchentoot.log, e.g.
[ERROR]] Error while processing connection: #\U4F60 (code 20320) is not a LATIN-1 character.

In 1.0 release,  *break-on-signals* is used to enter the debugger
In the old release and 1.1,  when *catch-errors-p* is set as nil, the debugger will be entered.
The related discussion thread can be found at:
http://common-lisp.net/pipermail/tbnl-devel/2009-November/004928.html

cheers
Li


2010/1/23 Ron Garret <ron@flownet.com>
That was the problem.  But why did it fail silently?  I would have expected something along the line to complain about a non-encodable character.

rg

On Jan 22, 2010, at 7:32 PM, Li Gong wrote:

What's the value of *hunchentoot-default-external-format* ?  By default,  it is +latin-1+
To support UTF-8,    change it as
(setf *hunchentoot-default-external-format* (flex:make-external-format :utf8 :eol-style :lf))

My website still uses hunchentoot 0.15.7。It returns the non-ascii character page and  always work fine.


2010/1/23 Ron Garret <ron@flownet.com>
Subject line says it all.  If I have a handler that returns a string that has a non-ascii character in it then the handler fails silently.  No headers.  No log messages.  No errors.  No nothing.

And as long as I'm at it, what does TBNL stand for?

Thanks,
rg


_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel


_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel