On 2010-09-30 13:36:17 +0100, Nick Keighley said:
there are some application domains where neither option would be
viewed as a satisfactory error handling strategy. Fly-by-wire, petro-
chemicals, nuclear power generation. Hell you'd expect better than
this from your phone!
People always give these kind of scenarios, but actually there are far
more mundane ones. In my day job I'm a sysadmin and I spend a bunch of
time writing code (typically what would nowadays be called "scripts"
rather than programs, but there's no real difference) which does things
of the form
for every machine in <several hundred systems>
do <something>
where <something> is fairly often "modify critical system configuration file".
Programs like that have some absolute, non-negotiable requirements:
- they must never fail silently;
- they must check everything they do however unlikely it seems that it
would failm
because they will come across systems which have almost arbitrary
misconfiguration.
- they should be idempotent if possible;
- if they come across something odd they either need to handle it,
or put things back the way they were and back out;
- if they absolutely can not put things back, they need to report this
very clearly
and carefully preserve any detriitus in such a way that a human can
pick up the bits;
- whatever they do they need to report in a completely parsable way
what happened
(success, failure, already done, backed out, not backed out, and so on).
These are quite mundane everyday things, but the consequences of
getting them wrong can be quite nasty (the worst ones being "the
machines will still run, but won't boot").
--
http://mail.python.org/mailman/listinfo/python-list
