exception handling in complex Python programs

[Maric Michaud]

Le Friday 22 August 2008 15:03:21 Bruno Desthuilliers, vous avez écrit :
> 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.

... or lose open connection, reset sessions, etc.. it doesn't really matter 
what is lost when a program crash, if it can be restarted without changes it 
is hardly what I'd qualify a "dramatic result". It doesn't depend on the 
language what implications of an unhandled error are, It is always 
application-specific.

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

I agree, this is my whole point, "whatever the language is".

> > 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/
>

I didn't read "dramatic results" in that sense, but with the meaning of a 
result that the program itself cannot handle.

If the whole system crash due to an unhandled error in a program, once 
missile's dropped it doesn't really matter in which language it was written. 
Reliability of a system, as high-availability of an application, is mostly a 
problem beyond the scope of application level error checking.

> >> 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.
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
_____________

Maric Michaud