[hunchentoot-devel] Hard to catch errors below process-request

[AVS]

Very simple. I get a string from server A. I expect the string to be
of latin characters. By (their) mistake there are a couple of unicode
characters in the string.
Now I want to use the string as part of my own server request handler
which I do via:
(defun handle-page-request ()
    (no-cache)
    *string-with-unicode*)

This request will produce an empty page. The developer says: "Why?! No
debugger was triggered, it went completely silent!".
The reason for that was when start-output called (string-to-octets
content :external-format (reply-external-format*)), the default
hunchentoot external-format is latin-1.
Since there are unicode characters in content variable,
string-to-octets will throw an exception which will not show anywhere.
Go figure it was a problem in your content string and that
string-to-octets blew up on it!
I understand that in most cases the developer writes some kind cl-who
code in the handler, or uses some content known to them.
But there are cases when you are dealing with 3-d party content which
you use to form your own.

To fix their problem I now create a handler like:
(defun handle-page-request ()
    (no-cache)
    (setf (hunchentoot:reply-external-format*)
(flex:make-external-format :utf-8 :eol-style :lf))
    (setf (hunchentoot:content-type*) "text/html; charset=utf-8")
    *string-with-unicode*)

Now, the problem I was talking about was that these types of errors
are hard to find.
If any exception thrown from within start-output triggered the
debugger I'd find the root cause of the problem in no time.

Thank you,
Andrei

On Thu, Jan 20, 2011 at 4:27 PM, Hans Hübner <hans.huebner at gmail.com> wrote:
> On Thu, Jan 20, 2011 at 10:20 PM, AVS <lispercat at gmail.com> wrote:
>> The issue is this: If any of the functions fail when called from
>> start-output, you'll receive an empty response and the debugger will
>> not catch which function caused the error.
>> I described in the previous message that in my case (string-to-octets
>> ..) failed. The failure may depend on your input.
>> I just said that to reproduce that scenario (silent error without
>> debugger being invoked) just put any failing function inside
>> start-output and issue a page request from the browser.
>> You'll receive an empty page and no debugger will be signaled.
>> Maybe it's a normal scenario, but it's hard to find the failing
>> function in this case.
>
> I'm just trying to find out how pressing the problem is - Is it
> something that a user or an application developer may run into, or is
> it something that just happens when you poke around in the source code
> and break it in unexpected ways?  From quickly glancing at
> start-output, I see no calls back into user code, but you have run
> into it nevertheless.  How, why?
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>