exception handling in complex Python programs
bruno.42.desthuilliers at websiteburo.invalid
Thu Aug 21 17:31:38 CEST 2008
eliben a écrit :
> On Aug 21, 12:40 pm, Bruno Desthuilliers <bruno.
> 42.desthuilli... at websiteburo.invalid> wrote:
>> eliben a écrit :> On Aug 19, 7:19 pm, eliben <eli... at gmail.com> wrote:
>>> 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).
More information about the Python-list