Here's what I found out, in case it helps someone.  Turns out I mis-
read the stack trace.  The exception happened AFTER calling my
handler, not before (trace messages in my handler didn't show up
because of buffering, reinforcing my incorrect theory that it hadn't
been invoked).

The issue was that in this one case I happened to be emitting some
valid text that contained the 0xc3 byte.  After my handler was
invoked, the framework was trying to gather the output using a
StringIO, which contains this warning:

    The StringIO object can accept either Unicode or 8-bit strings,
but
    mixing the two may take some care. If both are used, 8-bit strings
that
    cannot be interpreted as 7-bit ASCII (that use the 8th bit) will
cause
    a UnicodeError to be raised when getvalue() is called.

and that's exactly what happened to me.  Turns out because I was
inadvertently emitting a unicode string at one point, followed later
by the 0xc3 byte, it caused the exception.  Simply by wrapping the
unicode string in str(variable_name), I was able to make the problem
go away.  I'm not 100% sure I understand why, but emitting u"UTEST"
causes the exception but "TEST" does not (when the 0xc3 byte is also
present somewhere in the output).

It's a bit scary just how easy it is to lay a really obscure trap for
yourself like this.  I have to be very careful not to emit any unicode
strings, it seems.  Any guidance/advice appreciated.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to