Software Engineering for Students A Programming Approach

17.2 Fault detection by software 241
In general, it seems that compile-time checking is better than run-time checking.
However, run-time checking has the last word. It is vital because not everything can
be checked at compile time.
SELF-TEST QUESTION
17.2 Add to the list above checks that can only be done at run-time and
therefore, by implication, cannot be done at compile-time.
Incidentally, it is common practice to switch on all sorts of automatic checking for
the duration of program testing, but then to switch off the checking when development
is complete – because of concern about performance overheads. For example,
some C++ compilers allow the programmer to switch on array subscript checking (during
debugging and testing), but also allow the checking to be removed (when the program
is put into productive use). C.A.R Hoare, the eminent computer scientist, has
compared this approach to that of testing a ship with the lifeboats on board but then
discarding them when the ship starts to carry passengers.
We have looked at automatic checking for general types of fault. Another way of
detecting faults is to write additional software to carry out checks at strategic times
during the execution of a program. Such software is sometimes called an audit module,
because of the analogy with accounting practices. In an organization that handles
money, auditing is carried out at different times in order to detect any fraud. An
example of a simple audit module is a method to check that a square root has been
correctly calculated. Because all it has to do is to multiply the answer by itself, such a
module is very fast. This example illustrates that the process of checking for faults by
software need not be costly – either in programming effort or in run-time performance.
SELF-TEST QUESTION
17.3 Devise an audit module that checks whether an array has been sorted
correctly.
Another term used to describe software that attempts to detect faults is defensive programming.
It is normal to check (validate) data when it enters a computer system – for
example, numbers are commonly scrupulously checked to see that they only contain
digits. But within software it is unusual to carry out checks on data because it is normally
assumed that the software works correctly. In defensive programming the programmer
inserts checks at strategic places throughout the program to provide detection
of design errors. A natural place to do this is to check the parameters are valid at the
entry to a method and then again when a method has completed its work. This
approach has been formalized in the idea of assertions, explained below.