Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Nick Leaton <nickle@calfp.co.uk>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3102 bytes --]


Karel Th�nissen wrote:


> THERE COULD NOT POSSIBLY HAVE BEEN A ROLE FOR ASSERTIONS ON-FLIGHT
> 
> a) Having the assertions unchecked will cause exceptions somewhere later
> in the program (with probably the same disasterous effect) or give
> erroneous results. Very likely, either case will give raise to the
> destruction of the launcher. The only thing we do know for sure then is
> that program behaviour becomes hard to predict. As the software was not
> performing an essential task (oh irony), the latter may not have given
> problems for this launch (by luck rather than science), but from a
> software engineering point of view that makes no difference. It was
> known that the calculations were, in fact, superfluous, but the software
> was believed to be reliable and harmless and that was proven wrong. This
> time, it was an exception gone astray in the superfluous subsystem, next
> time it is in an essential part.

If I generalise what you say, running production code with assertions 
will not make a difference. However, there are things you can do. If
there
was an exception handler built, then it can make choices. In the Ariane
case,
an exception from the SRI post launch can be ignored. If you were
writting
a system that involved file handling then it could, perhaps try
something
to make a file handle or space available. For example, prompt the user
to empty a trash can.

> However, assertions and the like can be very useful on the ground.
> Proper tools can signify the assumptions and report them as ex-post
> specifications of the software module as a whole. Assumptions are all
> those assertions that raise exceptions that are not properly caught and
> handled by exception handlers. Then during assembly for Ariane 5, one
> would have seen that one of the assumptions regarding the SRI was not
> met. Assertions in this respect can be viewed as reporting aid from the
> programmer who made an essential design decision somewhere deep down in
> the software (it was documented somewhere, so the programmer(s) were
> aware of this design decision), up to those who are going to test,
> verify or use the software. Any tester or verifier worth his income
> would have noticed the invalid assumption (for Ariane 5) that emerged
> from the implementation.
> 
> Of course, there still is the possibility that these ex-post
> specifications would not be used, but that at least supposes an extra
> level of incompentency or negligence (by this I do not want to insult
> the people on the Ariane project by suggesting that currently there is
> incompetence or negligence).
> 
> Notice, that hand-crafted documentation or free formatted in-code
> comments are too unreliable for this purpose and that normal condition
> testings in the software do not necessarily signify assumptions.
> Therefore, assertions as a means of documentation add an additional
> layer of security that could not easily and reliably be obtained by
> other coding practices.

From personal experience I have found this to be the case. Being able to
test your comments is very useful!


-- 

Nick