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