exception handling in complex Python programs

[Bruno Desthuilliers]

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:
(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).