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@gmail.com wrote:
On Thu, Jan 20, 2011 at 10:20 PM, AVS lispercat@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@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel