Our Exception Standards -- What do you think?

Barry A. Warsaw barry at digicool.com
Sun Jan 28 01:21:23 EST 2001


>>>>> "DF" == Doug Fort <dougfort at downright.com> writes:

    DF> The Library Manual recommends deriving all exceptions from the
    DF> system Exception class.  This class has a member called 'args'
    DF> which is a tuple of the arguments presented in its
    DF> constructor.  The default __str__ operator simply returns the
    DF> args tuple as a string.

    DF>   ('aaa', 'bbb') I propose that we follow this standard, with
    DF> the enhancement of overloading the __str__ operator of
    DF> individual exception classes.

While I think it's a good idea to derive your application specific
exceptions from Exception, I don't think you necessarily need to use
its constructor.  The Exception class was carefully designed for
backwards compatibility but you don't have that problem.

When I design my exception classes, I usually create one derived class
per subsystem and then derive all my further exception classes from
those.  E.g.

Exception
 +-> ListError
 |    +-> UnknownListError
 |    +-> CorruptListError
 |    +-> ...
 |
 +-> AuthenticationError
 |    +-> BadPasswordError
 |    +-> CookieError
 |    |    +-> ExpiredCookieError
 |    |    +-> InvalidCookieError
 |    +-> ...
 |
 +-> ...

Then if I know that I'm going to raise the exception with some
specific arguments, I create an __init__() to accept only those
arguments (and a __str__() to print something reasonable using those
arguments).  I often do not call Exception.__init__() in my own
classes's constructor.

Cheers,
-Barry




More information about the Python-list mailing list