exception handling in complex Python programs

[magloca]

Bruno Desthuilliers @ Thursday 21 August 2008 22:54:

> magloca a écrit :
>> Bruno Desthuilliers @ Thursday 21 August 2008 17:31:
>> 
>>>>> 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.
>> 
>> Could you elaborate on that? I'm not disagreeing with you (or
>> agreeing, for that matter); I'd just really like to know what you
>> mean by a "total disaster."
> 
> One of the most (in)famous Java coding pattern is the empty catchall
> clause. Read Chris Mellon and Richard Levasseur posts in this thread
> for more details - they already covered the whole point.

Thanks, I missed those. Having read them, I *am* agreeing with you.
Personally, I also dislike the predominance in the Java world of only
giving type information -- IllegalValueException,
ObjectRetrievalFailureException, and whatever. What was the illegal
value? What object couldn't be retrieved? How hard is it to use the
with-error-message version of the Exception constructor, and include
something that might actually be helpful in debugging?

m.