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

[AVS]

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.

Thank you,
Andrei


On Thu, Jan 20, 2011 at 4:04 PM, Hans Hübner <hans.huebner at gmail.com> wrote:
> On Thu, Jan 20, 2011 at 8:48 PM, AVS <lispercat at gmail.com> wrote:
>> The easiest I can think of is to put some garbage inside start-output
>> function (headers.lisp) and execute a request from any server running
>> on hunchentoot.
>> Let's say right after
>>    (when (stringp content)
>>      ;; if the content is a string, convert it to the proper external format
>>      (setf content (string-to-octets content :external-format
>> (reply-external-format*))))
>>
>> put something like (/ 1 0) or (crazy-function a b).
>> I wonder if I can write a test case to isolate it more so you wouldn't
>> have to use your server code.
>
> I'm not sure if I understand you well, but are you changing
> Hunchentoot itself and find it hard to debug, or are you writing an
> application that uses Hunchentoot and find _that_ hard to debug.  If
> the former, I think you'll have to come up with a proposed patch to
> improve the behavior.  If the latter, I think I don't quite understand
> what the issue is.
>
> -Hans
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>