How should I document exceptions thrown by a method?
Chris Torek
nospam at torek.net
Wed Jul 27 21:47:18 EDT 2011
>Arcadio <arcadiosincero at gmail.com> writes:
>> I have a Settings class that is used to hold application settings. A
>> Settings object initializes itself from a ConfigParser that gets
>> passed in as an argument to the constructor.
In article <87oc0fpg9o.fsf at benfinney.id.au>
Ben Finney <ben+python at benfinney.id.au> wrote:
>So the caller is aware of, and takes responsibility for, the
>ConfigParser instance.
>> If a setting isn't found in whatever the ConfigParser is reading
>> settings from, the ConfigParser's get() method will raise an
>> exception. Should I just say that clients of my Settings class should
>> be prepared to catch exceptions thrown by ConfigParser? Do I even have
>> to mention that as it might be just implied?
>
>In this case IMO it is implied that one might get exceptions from the
>object one passes as an argument to a callable.
Yes. But on the other hand:
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
...
:-)
I would suggest that in this case, too, "explicit is better than
implicit": the documentation should say "will invoke x.get() and
therefore propagate any exception that x.get() might raise".
>> Or should Setting's constructor catch any exceptions raised by the
>> ConfigParser and "convert it" to a Settings- specific exception class
>> that I then document?
>
>Please, no. Since the ConfigParser object was created and passed in by
>the calling code, the calling code needs to know about the exceptions
>from that object.
In *some* cases (probably not applicable here), one finds a good
reason to transform one exception to another. In this case I agree
with Ben Finney though, and so does "import this":
...
Simple is better than complex.
...
Letting exceptions flow upward unchanged is (usually) simpler,
hence "better".
--
In-Real-Life: Chris Torek, Wind River Systems
Intel require I note that my opinions are not those of WRS or Intel
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
More information about the Python-list
mailing list