eliben a écrit :
On Aug 21, 12:40 pm, Bruno Desthuilliers <bruno.
[EMAIL PROTECTED]> wrote:
eliben a écrit :> On Aug 19, 7:19 pm, eliben <[EMAIL PROTECTED]> wrote:
(snip)
"""
Document the exceptions thrown by your code
"""
If you mean "the exceptions *explicitely raised* by your code", then I
agree. But with any generic enough code, documenting any possible
exception that could be raised by lower layers, objects passed in as
arguments etc is just plain impossible. Like, if you have a function
that takes a file-like object as arg, you just cannot know in advance
what exceptions this object might raise.
This is one of the main concerns with which I started this c.l.py
thread ! I think it's a pity that we have no way of anticipating and
constraining the exceptions thrown by our code,
Java's "checked exception" system has proven to be a total disaster.
and that we should
strive to make it more explicit. The "function accepting a file" is a
case in point. You know what you do with this file, so why can't you
know what exceptions might be thrown ?
Reread more carefully. I wrote "a *file-like* object", not "a file".
This is the whole point of duck typing. Given that any file-like object
will work ok with my function, I have *no way* to know what exceptions
this object may raise.
If you're trying to open it,
Trying to open a file *object* ? heck, it's supposed to be already
opened at this stage. And yes, it's a pretty common pattern in Python
(which is why I choose this example).
--
http://mail.python.org/mailman/listinfo/python-list
