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