> 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? BTW, I don't say that we have to skip `six.text_type(exc)` approach. I'm just saying, that it's not a panacea in real world. > six.text_type(exc) is the recommended solution As I mention in first letter, I vote for this solution since it's a general case. On Fri, May 16, 2014 at 4:03 PM, Johannes Erdfelt <[email protected]>wrote: > On Fri, May 16, 2014, Igor Kalnitsky <[email protected]> wrote: > > > According to http://legacy.python.org/dev/peps/pep-0352/ the message > > > attribute of BaseException is deprecated since Python 2.6 and was > > > dropped in Python 3.0. > > > > Some projects have custom exception hierarchy, with strictly defined > > attributes (e.g. message, or something else). In a previous mail, I > > mean exactly that case, not the case with a built-in exceptions. > > That's a fragile assumption to make. > > unicode(exc) (or six.text_type(exc)) works for all exceptions, built-in > or custom. I don't see the reason why it's being avoided. > > JE > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
