2.

4 Software development

2.4.2 Program testing

2.4.2 Program testing

Types of programming Errors

There are several types of errors, with consequences ranging from deficiencies in the formatting of the output
to the calculation of wrong results. A compilation error (which prevents the compiler from compiling the
source code) is usually a syntax error but could be an error in the compiler itself. A syntax error results when
the source code does not obey the rules of the language. The compiler generates error messages to help the
programmer to fix the code. The source code may compile to machine code which then fails upon execution.
A run-time error causes this situation. Potentially the most serious type of error occurs when the program
appears to be working but is performing faulty processing due to logic errors in the source code. We classify
the common errors as syntax errors, run-time errors, and logic errors, but begin with three very common errors
for beginners that do not fit neatly into any of these categories.

Common Syntax Errors

Do not be discouraged if your first program generates many error messages. Often there are cascading errors,
in which a single mistake such as a misspelled identifier in a variable declaration gives rise to several error
messages. You then make one correction and several messages disappear at once. In the following table
showing extracts from error messages to look out for, note how some messages are much more helpful than
others.

Page 1 of 7
 2.4 Software development

2.4.2 Program testing

Description of error Typical message content Typical message content Comment

in Delphi in Lazarus
Misspelled identifier Undeclared identifier Identifier not found Spelling of identifier must be
consistent
Semicolon immediately ';' not allowed before ";" expected but The if … then … else is one
before else 'ELSE' "ELSE" found statement and should not
have a semicolon
immediately beforeelse.
Use of := instead of = in test Type of expression must "THEN" expected but
of equality be BOOLEAN ":=" found

e.g. if Total := 10 then ...

Identifier of variable ',' or ':' expected but … ":" expected but …
contains space

e.g. var my num : real;

Identifier of variable begins identifier/declaration BEGIN" expected but Identifier must begin with
with digit expected but number "ordinal const" found letter or underscore
found
e.g. var 2ndPlace:string;
Identifier of procedure identifier expected but "identifier" expected but Identifier must begin with
begins with digit number found "ordinal const" found letter or underscore

e.g. procedure 5Times;

Use of double quotes instead Illegal character in input Illegal character ($22)
of single quotes to enclose a file ($22)
string literal

e.g. Surname := "Coe";

String literal not enclosed by Undeclared identifier Identifier not found
quotes

e.g. Forename := Joe;

Use of round brackets to Missing operator or ";" expected but "(" found Use square brackets to
enclose array index semicolon enclose array index.

e.g.MyArray(63)
Real number starts with Expression expected but '.' Illegal expression Include the leading 0 e.g.
decimal point found
MyReal := 0.34;
e.g. MyReal := .34;
Argument type does not Incompatible types Incompatible types
match parameter type when
Page 2 of 7
 2.4 Software development

2.4.2 Program testing

calling a subroutine
Expression operated on by Operator not applicable to Incompatible types Should be:
logical operators not this operand type
enclosed in brackets. until (Count = MAX) or
Found;
e.g.until Count = MAX or
Found;

Description Example Comment

Missing type check, allowing Letter "a" entered and assigned to Validate entered data.
wrong type of data to be entered integer variable
Index of array not within declared Example of INCORRECT code: If the user hits a wrong key (e.g. 5
array bounds instead of 4) there could be a run-time
programArrayBounds; error.
{$APPTYPE CONSOLE}{$R+}
uses The compiler directive {$R+} enables
SysUtils; run-time checking of ranges. With the
const default directive {$R-}, the effects of the
Sales : array[1..4] ofinteger = user's mistake are difficult to predict.
(2435, 3423, 3410, 2865);
var Include validation code to accept only the
Index : integer; digits 1 to 4.
begin
write('View sales for which
quarter? ' +
'1, 2, 3 or 4 ');
readln(Index);
writeln(Sales[Index]);
readln;
end.
Overflow e.g. when a number is Example of INCORRECT code: The compiler directive {$Q+} enables
too large to be held in the type of run-time checking of overflow. With the
variable used program Overflow; default {$Q-}, the program runs and
{$APPTYPE CONSOLE}{$Q+} outputs a negative number of
uses milliseconds in January! An integer is
SysUtils; held in two's complement format, which
var represents a negative number when the
MillisecsPerDay, Jan_ms : most significant bit is 1.

Page 3 of 7
 2.4 Software development

2.4.2 Program testing

integer;
{Use int64 instead of integer to
make
this program work.}
begin
MillisecsPerDay := 24 * 60 * 60 *
1000;

Jan_ms := MillisecsPerDay * 31;

writeln(Jan_ms);
readln;
end.

Page 4 of 7
 2.4 Software development

2.4.2 Program testing

Common Run-time errors

Some errors cannot be detected by the compiler and only become apparent at run time. For example, errors
which depend on the input from a user cannot be predicted by the compiler.

Division by 0 Example of INCORRECT code: An entry of 0 for Time will cause a

run-time error when Speed is
programDivisionByZero; calculated. The program needs
{$APPTYPE CONSOLE} validation to ensure that Time is
uses greater than zero. (It also needs type
SysUtils; checking, perhaps using
var the val procedure, to accept only
Distance, Time, Speed : real; valid numbers
begin for Distance and Time).
write('Distance in m? ');
readln(Distance);
write('Time in s? ');
readln(Time);
Speed := Distance / Time;
write('Speed in m/s: ');
writeln(Speed : 6 : 2);
readln;
end.
Infinite loop Example of INCORRECT code: The integer Num "misses" the end
of the loop, which continues to run.
Num := 0; Use safe conditions such as
repeat
Num := Num + 3; untilNum>= 10
untilNum = 10; in this example.

Page 5 of 7
 2.4 Software development

2.4.2 Program testing

Common logic errors

When you have removed all the syntax errors, compile-time errors and run-time errors you may think it is
time to heave a huge sigh of relief - but don't forget that there may still be logical errors lurking in your
program.

Out-by-one (or off-by-one) errors are very common, hence the emphasis on boundary testing in computing
courses. The cause of the error is often the operator used, as in the first example below.

Description Example Comment

Out-by-one Example of INCORRECT code: The >= operator should have been used
instead of >.
if Marks[i] >PassMarkthen
inc(NumberOfPasses);
Out-by-one Example of INCORRECT code: The calculated number of coaches may be
one less than required.
NumCoaches :=
NumPeopleDIVSeatingCapacity;
Missing begin and end to Example of INCORRECT code: This code will assign True to Foundwhether
group statements intended to or not the condition is true. This error is often
be run together depending on if Names[i] = SearchNamethen made when adding an instruction to existing
some condition writeln('Found at position ', i); code. If you always
Found := True; use begin and end after then,else and do,
your programs will be safeguarded from this
type of error.
Semicolon immediately Example of INCORRECT code: In this code the for loop has no code to
after then,else or do execute other than incrementing i. After the
fori := 1 to 10 do; loop, the writeln statement is executed once
writeln('Line ', i); using the final value of i.
Operator precedence not what Example of INCORRECT code: The operators * and / have precedence
is required to give the right over + and -. In order to perform the
answer Celsius := Fahrenheit - 32 * 5 / 9 subtraction first, the expression Fahrenheit -
32 should be enclosed in brackets.

Tip: If you are unsure of the operator

precedence, use brackets to force the order of
calculation to be the one you require.

How can I avoid making mistakes while coding any program?

Follow these tips to reduce the number of errors in your programs:

Page 6 of 7
 2.4 Software development

2.4.2 Program testing

Take frequent breaks; mistakes are more likely when you are tired.
If in doubt, check. Look at examples if you are unsure of the correct syntax. Read the checklists above
from time to time and be on the lookout for those mistakes.
Learn from your mistakes. Try to recognize the types of mistake you make most often and concentrate
on reducing those.
Do not rely on the compiler to find your mistakes; it will only find certain types of mistake.
Check the computer output carefully to make sure it is correct. Your tests should include normal,
boundary and erroneous data. See our sample test plan in the tutorial on testing.
Include checks in the program itself, such as validating the input and intermediate results.
Try your hand at spotting the errors in our selection of Programs to Debug. See how many of our
deliberate errors you are able to spot and fix.

Page 7 of 7