With modern Python Exceptions, you don't need to abuse .message, or override .__str__() or .__repr__() or any of it. If all you want is an informative message when your exception is raised, do this:

class MyException(Exception):
    pass

raise MyException("My hovercraft is full of eels")

That will give a traceback ending with MyException: My hovercraft is full of eels.

If you want more flexibility from the exception, you could pass a dictionary as the argument:

raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})

However, to get at those details in an except block is a bit more complicated. The details are stored in the args attribute, which is a list. You would need to do something like this:

try:
    raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
except MyException as e:
    details = e.args[0]
    print(details["animal"])

It is still possible to pass in multiple items to the exception and access them via tuple indexes, but this is highly discouraged (and was even intended for deprecation a while back). If you do need more than a single piece of information and the above method is not sufficient for you, then you should subclass Exception as described in the tutorial.

class MyError(Exception):
    def __init__(self, message, animal):
        self.message = message
        self.animal = animal
    def __str__(self):
        return self.message

Exception classes should be as specific as error handling might need to be.

Think about using your code: when each error is raised, how would you want to handle it?

• Errors that must be handled the same way should be the same class.
• Errors that you don't see a good reason to handle separately can be the same class until you find a reason.
• Errors that a user might sometimes have good reason to distinguish should be distinct classes.
  • If one error is a special case of a more general error that you have, make the former a subclass of the latter.
  • If they're just different errors, don't have a subclass relationship between them.

PEP-8 recommends the same thing:

Design exception hierarchies based on the distinctions that code catching the exceptions is likely to need, rather than the locations where the exceptions are raised. Aim to answer the question “What went wrong?” programmatically, rather than only stating that “A problem occurred” (see PEP 3151 for an example of this lesson being learned for the builtin exception hierarchy)

Error codes are at best a low-level implementation detail leaking into your abstractions. Python is a language where it's both beneficial and equally easy to just express each error as a distinct type. So error codes are only justified when you are wrapping a third-party library which already has error codes, and you can't just easily provide a good error class hierarchy over the error codes to better represent the semantics of the errors.