exception handling in complex Python programs

[Bruno Desthuilliers]

Maric Michaud a écrit :
> Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
>>> The point
>>> is that EAFP conflicts with the interest of reporting errors as soon
>>> as possible (on which much has been written see, for instance Ch. 8 -
>>> Defensive Programming in Code Complete),
>> Defensive programming makes sense in the context of a low-level language
>>    like C where errors can lead to dramatic results. In high-level
>> languages like Python, the worse thing that an unhandled exception can
>> cause is an abrupt termination of the process and a nice traceback on
>> screen.
> 
> ... and leave your datas in inconsistent state.

Not all applications persist data, so this is an application-specific 
problem, to be solved at the application level - IOW, there's no 
one-size-fits-all solution here. Anyway: transactions management is not 
what I meant when talking about defensive programming.

As far as I'm concerned, the only place where the defensive approach 
really makes sense whatever the language is when dealing with external 
datas (user inputs etc).

> So, what C or any other 
> language could do worse to your application ?

An error in a C program can do *way* worse than leave an application's 
data in inconsistent state. See ART for more on this:
http://dialspace.dial.pipex.com/prod/dialspace/town/green/gfd34/art/

>> In this context, defensive programming is mostly a waste of time 
>> - if you can't *correctly* handle the exception where it happens, then
>> doing nothing is the better solution.
> 
> If I don't buy the argument

cf above - maybe you buy it after all ?-)

> I actually agree with the conclusion. Each 
> component of a program should try to manage only errors tied to their own 
> logic and let pass others up to the gui logic for rendering errors the good 
> way, persistence logic to rollback unwanted changes, and application logic to 
> continue execution the right way. This is hard to do in C because you have no 
> way to trap an error which happen randomly in the program, ie. a segfault 
> will interrupt the execution anyway.

Indeed.