<div dir="ltr"><div><b>@Victor:</b></div><div><br></div><div>> " six.text_type(exc): always use Unicode. It may raise unicode error depending</div><div>> on the exception, be careful. Example of such error in python 2:</div>
<div>> unicode(Exception("nonascii:\xe9")). "</div><div><br></div><div>It's very rare situation. Actually, it's no sense since we know nothing</div><div>about exception's encoding. Without encoding it's nothing more, but</div>
<div>bytes, while logging is a text stream first of all.</div><div><br></div><div>So I agree with @Johannes here. We need to use unicode for text streams,</div><div>or at least ASCII-compatible str objects.</div><div><br>
</div><div><br></div><div><b>@Johannes:</b></div><div><br></div><div>> If a third party library raises exceptions with strings in an encoding</div><div>> other than ASCII, they should be shot :)</div><div><br></div>
<div>+1</div><div><br></div><div><br></div><div>> I don't understand the problem.</div><div>> </div><div>> What are you expecting from unicode(exc)? What exceptions don't meet</div><div>> that expectation?</div>
<div><br></div><div>Sorry if you misunderstood me. My point is sometimes str() or unicode()</div><div>don't give us the result we expecting for because of user's exception</div><div>hierarchy.</div><div><br></div>
<div>For instance, web.py's exception just shows you a status code, and doesn't</div><div>print the exception's message. The problem is in library, not in approach,</div><div>but shit happens and I don't see problems with using direct access to</div>
<div>attribute, if library's documentation gives a grantee that we can use</div><div>attributes for getting exception message.</div><div><br></div><div>In that case, I propose not to do an explicit conversion, and leave</div>
<div>this task for logging module.</div><div><br></div><div><br></div><div>- Igor</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 18, 2014 at 2:03 AM, Johannes Erdfelt <span dir="ltr"><<a href="mailto:johannes@erdfelt.com" target="_blank">johannes@erdfelt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, May 16, 2014, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>

</div><div class="">> > unicode(exc) (or six.text_type(exc)) works for all exceptions, built-in or<br>
> custom.<br>
><br>
> That's too much of a statement. Sometimes exceptions implement their own<br>
> __str__ / __unitcode__<br>
> methods, that return too many rubbish information or not enough. What do<br>
> you do in that case?<br>
<br>
</div>I don't understand the problem.<br>
<br>
What are you expecting from unicode(exc)? What exceptions don't meet<br>
that expectation?<br>
<br>
Using str(exc) or unicode(exc) is the standard Python convention to get<br>
a useful string out of an exception. This is what the traceback module<br>
does (at least in Python 2.7) for the last line in the traceback output.<br>
<br>
It tries str first, then unicode if str fails. If it uses unicode, then<br>
it backslash escapes it back to ASCII.<br>
<br>
The behavior to try str first and then unicode second appears to be<br>
because of legacy reasons.<br>
<br>
I'm not entirely sure why it backslash escapes unicode back to ASCII.<br>
Maybe to avoid a possible second exception when printing it?<br>
<div class="HOEnZb"><div class="h5"><br>
JE<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>