Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-03 00:21:55


"Dan W." <danw_at_[hidden]> wrote in message
news:bt430m$eb2$1_at_sea.gmane.org...

> Remember the case of that Arienne 5 rocket that crashed due to a
> software glitch? There was a thread that monitored horizontal wind at
> the lunch pad. It was supposed to stop working 40 seconds after launch,
> but didn't because the countdown was stopped and then re-started too
> soon, so it got confused. About 3 minutes into flight, its output
> wasn't even being used, but it saw winds that were higher than the range
> of its input, threw an exception, and all 3 computers crashed.

I've seen this episode in Bertrand Meyer's OO book, in several Software
Engineering books
and I don't get it. They always seem to advocate, that "had they just done
as I say, the accident could have
been prevented". I don't think the world of software devollopment is that
simple and I have long time ago
lost my respect for the many software engineers and their so-called
research. As Bjane Stroupstrup put it,
no single unit can make the whole thing work. And I'm reminded about the
first fact in Robert Glass' Facts and Fallacies
of Software Engineering: the quality of the programmers (not their tools or
techniques) is what matters most.

> But this is not the problem of assertions and DBC. Assertions and DBC
> are just fuses to debug code.

why? They are certainly also for documenting code. And documenting exception
specs can be
a lot of work.

>They can have, and must have, a default
> policy. This is why I would be terribly disappointed to see DBC getting
> mixed up with exceptions or error logging. I think most of us
> programmers are already confused enough, as to what to use, when.

Throwing an exception is sometimes a lot better than terminating the entire
program. Imagine
a big application in which a sub-app fails. So how does Eiffel document
exceptions?

br

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk