Page 374 -

13.4 Dependable programming 357

positive integer. In many cases, however, the system specification does not define
what actions should be taken if the input is incorrect. Inevitably, users will make
mistakes and will sometimes enter the wrong data. Sometimes, as I discuss in
Chapter 14, malicious attacks on a system rely on deliberately entering incorrect
input. Even when the input comes from sensors or other systems, these systems can
go wrong and provide incorrect values.
You should therefore always check the validity of inputs as soon as these are read
from the program’s operating environment. The checks involved obviously depend
on the inputs themselves but possible checks that may be used are as follows:

1. Range checks You may expect inputs to be within a particular range. For exam-
ple, an input that represents a probability should be within the range 0.0 to 1.0;
an input that represents the temperature of a liquid water should be between 0
degrees Celsius and 100 degrees Celsius, and so on.

2. Size checks You may expect inputs to be a given number of characters (e.g.,
eight characters to represent a bank account). In other cases, the size may not be
fixed but there may be a realistic upper limit. For example, it is unlikely that a
person’s name will have more than 40 characters.
3. Representation checks You may expect an input to be of a particular type,
which is represented in a standard way. For example, people’s names do not
include numeric characters, e-mail addresses are made up of two parts, separated
by a @ sign, etc.

4. Reasonableness checks Where an input is one of a series and you know some-
thing about the relationships between the members of the series, then you can
check that an input value is reasonable. For example, if the input value repre-
sents the readings of a household electricity meter, then you would expect the
amount of electricity used to be approximately the same as in the corresponding
period in the previous year. Of course, there will be variations but order of mag-
nitude differences suggest that a problem has arisen.

The actions that you take if an input validation check fails depend on the type of
system being implemented. In some cases, you report the problem to the user and
request that the value be reinput. Where a value comes from a sensor, you might use
the most recent valid value. In embedded real-time systems, you might have to esti-
mate the value based on history, so that the system can continue in operation.

Guideline 3: Provide a handler for all exceptions
During program execution, errors or unexpected events inevitably occur. These may
arise because of a program fault or may be a result of unpredictable external circum-
stances. An error or an unexpected event that occurs during the execution of a program
is called an ‘exception’. Examples of exceptions might be a system power failure, an
attempt to access non-existent data, or numeric overflow or underflow.