Home » Python » BaseException.message deprecated in Python 2.6

BaseException.message deprecated in Python 2.6

Posted by: admin November 1, 2017 Leave a comment

Questions:

I get a warning that BaseException.message is deprecated in Python 2.6 when I use the following user-defined exception:

class MyException(Exception):

    def __init__(self, message):
        self.message = message

    def __str__(self):
        return repr(self.message)

This is the warning:

DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
self.message = message

What’s wrong with this? What do I have to change to get rid of the deprecation warning?

Answers:

Solution – almost no coding needed

Just inherit your exception class from Exception and pass the message as the first parameter to the constructor

Example:

class MyException(Exception):
    """My documentation"""

try:
    raise MyException('my detailed description')
except MyException as my:
    print my # outputs 'my detailed description'

You can use str(my) or (less elegant) my.args[0] to access the custom message.

Background

In the newer versions of Python (from 2.6) we are supposed to inherit our custom exception classes from Exception which (starting from Python 2.5) inherits from BaseException. The background is described in detail in PEP 352.

class BaseException(object):

    """Superclass representing the base of the exception hierarchy.
    Provides an 'args' attribute that contains all arguments passed
    to the constructor.  Suggested practice, though, is that only a
    single string argument be passed to the constructor."""

__str__ and __repr__ are already implemented in a meaningful way,
especially for the case of only one arg (that can be used as message).

You do not need to repeat __str__ or __init__ implementation or create _get_message as suggested by others.

Questions:
Answers:

Yes, it’s deprecated in Python 2.6 because it’s going away in Python 3.0

BaseException class does not provide a way to store error message anymore. You’ll have to implement it yourself. You can do this with a subclass that uses a property for storing the message.

class MyException(Exception):
    def _get_message(self): 
        return self._message
    def _set_message(self, message): 
        self._message = message
    message = property(_get_message, _set_message)

Hope this helps

Questions:
Answers:
class MyException(Exception):

    def __str__(self):
        return repr(self.args[0])

e = MyException('asdf')
print e

This is your class in Python2.6 style. The new exception takes an arbitrary number of arguments.

Questions:
Answers:

As far as I can tell, simply using a different name for the message attribute avoids the conflict with the base class, and thus stops the deprecation warning:

class MyException(Exception):

def __init__(self, message):
    self.msg = message

def __str__(self):
    return repr(self.msg)

Seems like a hack to me.

Maybe someone can explain why the warning is issued even when the subclass defines a message attribute explicitly. If the base class no longer has this attribute, there shouldn’t be a problem.

Questions:
Answers:

How to replicate the warning

Let me clarify the problem, as one cannot replicate this with the question’s sample code, this will replicate the warning:

>>> error = Exception('foobarbaz')
>>> error.message
__main__:1: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
'foobarbaz'

Eliminating the warning while still using .message

And the way you get rid of the DeprecationWarning is to subclass a builtin exception as the Python designers intended:

class MyException(Exception):

    def __init__(self, message, *args):
        self.message = message
        # delegate the rest of initialization to parent
        super(MyException, self).__init__(message, *args)

>>> myexception = MyException('my message')
>>> myexception.message
'my message'
>>> str(myexception)
'my message'
>>> repr(myexception)
"MyException('my message',)"

Alternatively, avoid the .message attribute

However, it is probably preferable to avoid the message attribute to begin with and just take the str of the error. Just subclass Exception:

class MyException(Exception):
    '''demo straight subclass'''

And usage:

>>> myexception = MyException('my message')
>>> str(myexception)
'my message'

See also this answer:

Proper way to declare custom exceptions in modern Python?

Questions:
Answers:

Continuing on from geekQ’s answer, the preferred code replacement depends on what you need to do:

### Problem
class MyException(Exception):
    """My documentation"""

try:
    raise MyException('my detailed description')
except MyException as my:
    ### Solution 1, fails in Python 2.x if MyException contains ?
    # with UnicodeEncodeError: 'ascii' codec can't encode characters in position 24-25: ordinal not in range(128)
    print(my)  # outputs 'my detailed description'

### Solution 2
# Works in Python 2.x if exception only has ASCII characters,
# should always work in Python 3.x
str(my)

### Solution 3
# Required in Python 2.x if you need to handle non-ASCII characters,
# such as δσφφδσ (as pointed out by jjc) or emoji ? ? ? ? ?
# but does not work in Python 3.x
unicode(my)

Sometimes exceptions have more than one argument, so my.args[0] is not guaranteed to provide all the relevant information.

For instance:

# Python 2.7
try:
    u'\u12345'.encode('utf-8').encode('utf-8')
except UnicodeDecodeError as e:
    print e.args[0]
    print e.args
    print str(e)

Prints as output:

ascii
('ascii', '\xe1\x88\xb45', 0, 1, 'ordinal not in range(128)')
'ascii' codec can't decode byte 0xe1 in position 0: ordinal not in range(128)

However it’s a context sensitive trade off, because for instance:

# Python 2.7
>>> str(SyntaxError())
'None'
# 'None' compares True which might not be expected

Questions:
Answers:

The advice to use str(myexception) leads to unicode problems in python 2.7, e.g.:

str(Exception(u'δσφφδσ'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-5: ordinal not in range(128)

🙁

unicode(Exception(u'δσφφδσ')) 

works as expected, and is preferred in cases where some of the content of the error string includes user input

Questions:
Answers:

pzrq’s post says to use:

str(e)

This was exactly what I needed.

(If you are in a unicode environment, it appears that:

unicode(e)

will work, and it appears to work fine in a non-unicode environment)

Pzrq said a lot of other good stuff, but I almost missed their answer due to all the good stuff. Since I don’t have 50 points I cannot comment on their answer to attempt to draw attention to the simple solution that works, and since I don’t have 15 I cannot vote that answer up, but I can post (feels backward, but oh well) – so here I am posting – probably lose points for that…

Since my point is to draw attention to pzrq’s answer, please don’t glaze over and miss it in all the below. the first few lines of this post are the most important.

My story:

The problem I came here for was if you want to catch an exception from a class that you have no control over – what then??? I’m certainly not going to subclass all possible classes my code uses in an attempt to be able to get a message out of all possible exceptions!

I was using:

except Exception as e:
   print '%s (%s)' % (e.message,type(e))

which, as we all now know, gives the warning OP asked about (which brought me here), and this, which pzrq gives as a way to do it:

except Exception as e:
   print '%s (%s)' % (str(e),type(e))

did not.

I’m not in a unicode environment, but jjc’s answer made me wonder, so I had to try it. In this context this becomes:

except Exception as e:
   print '%s (%s)' % (unicode(e),type(e))

which, to my surprise, worked exactly like str(e) – so now that’s what I’m using.

Don’t know if ‘str(e)/unicode(e)’ is the ‘approved Python way’, and I’ll probably find out why that’s not good when I get to 3.0, but one hopes that the ability to handle an unexpected exception (*) without dying and still get some information from it won’t ever go away…

(*) Hmm. “unexpected exception” – I think I just stuttered!