Open Stack

*@Victor:*

> " six.text_type(exc): always use Unicode. It may raise unicode error
depending
> on the exception, be careful. Example of such error in python 2:
> unicode(Exception("nonascii:\xe9")). "

It's very rare situation. Actually, it's no sense since we know nothing
about exception's encoding. Without encoding it's nothing more, but
bytes, while logging is a text stream first of all.

So I agree with @Johannes here. We need to use unicode for text streams,
or at least ASCII-compatible str objects.


*@Johannes:*

> If a third party library raises exceptions with strings in an encoding
> other than ASCII, they should be shot :)

+1


> I don't understand the problem.
>
> What are you expecting from unicode(exc)? What exceptions don't meet
> that expectation?

Sorry if you misunderstood me. My point is sometimes str() or unicode()
don't give us the result we expecting for because of user's exception
hierarchy.

For instance, web.py's exception just shows you a status code, and doesn't
print the exception's message. The problem is in library, not in approach,
but shit happens and I don't see problems with using direct access to
attribute, if library's documentation gives a grantee that we can use
attributes for getting exception message.

In that case, I propose not to do an explicit conversion, and leave
this task for logging module.


- Igor



On Sun, May 18, 2014 at 2:03 AM, Johannes Erdfelt <johannes at erdfelt.com>wrote:

> On Fri, May 16, 2014, Igor Kalnitsky <ikalnitsky at mirantis.com> wrote:
> > > unicode(exc) (or six.text_type(exc)) works for all exceptions,
> built-in or
> > custom.
> >
> > That's too much of a statement. Sometimes exceptions implement their own
> > __str__ / __unitcode__
> > methods, that return too many rubbish information or not enough. What do
> > you do in that case?
>
> I don't understand the problem.
>
> What are you expecting from unicode(exc)? What exceptions don't meet
> that expectation?
>
> Using str(exc) or unicode(exc) is the standard Python convention to get
> a useful string out of an exception. This is what the traceback module
> does (at least in Python 2.7) for the last line in the traceback output.
>
> It tries str first, then unicode if str fails. If it uses unicode, then
> it backslash escapes it back to ASCII.
>
> The behavior to try str first and then unicode second appears to be
> because of legacy reasons.
>
> I'm not entirely sure why it backslash escapes unicode back to ASCII.
> Maybe to avoid a possible second exception when printing it?
>
> JE
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/f70ba2a4/attachment.html>