Programming is a complex
process, and since it is done by human beings, it often leads to
errors. For whimsical reasons, programming errors are called bugs and
the process of tracking them down and correcting them is called
Fun Note: The very early
computers did not use transistors and integrated circuits but used
vacuum tubes, which operated at very high voltages – or in some cases,
even electromechanical relays. It was not unusual for a real bug to get
electrocuted inside the machine and affect operation – thus hardware
“bugs” were a real problem.
There are a few different
kinds of errors that can occur in a program, and it is useful to
distinguish between them in order to track them down more quickly.
Compile-time errors. The compiler can only translate a program if t
he program is syntactically correct; otherwise, the compilation fails
and you will not be able to run your program. Syntax refers to the
structure of your program and the rules about that structure. For
example, in English, a sentence must begin with a capital letter and
end with a period. This sentence contains a syntax error. So does this
one For most readers, a few syntax errors are not a significant
problem, which is why we can read the poetry of E. E. Cummings without
spewing error messages. Compilers are not so forgiving. If there is a
single syntax error anywhere in your program, the compiler will print
an error message and quit, and you will not be able to run your
program. To make matters worse, there are more syntax rules in C++ than
there are in basic English, and the error messages you get from the
compiler are often not very helpful. During the first few weeks of your
programming experience, you will probably spend a lot of time tracking
down syntax errors. As you gain experience, though, you will make fewer
errors and find them faster.
. The second type of error is a run-time error, so-called because the
error does not appear until you run the program. For the simple sorts
of programs we will be writing, run-time errors are rare, so it might
be a little while before you encounter one. A good example of run-time
error is a division by zero. At the moment Web Cartoon Maker does not
have a debugger yet and in case of a runtime error you may receive a
message like “unknown error”.
The third type of error is the logical or semantic error. If there is a
error in your program, it will compile and run successfully, in the
sense that the computer will not generate any error messages, but it
will not do the right thing. It will do something else. In our case
events in animated cartoon may be different than we expected.
Specifically, it will do what you told it to do. The problem is that
the program you wrote is not the program you wanted to write. The
meaning of the program (its semantics) is wrong. Identifying logical
errors can be tricky, since it requires you to work backwards by
looking at the output of the program and trying to figure out what it
is doing. In these cases it may be necessary to add code to your
program for the specific purpose of aiding in locating the logical
One of the most important
skills you should acquire from working with this book is debugging.
Although it can be frustrating, debugging is one of the most
intellectually rich, challenging, and interesting parts of programming.
In some ways debugging is like detective work. You are confronted with
clues and you have to infer the processes and events that lead to the
results you see.
Debugging is also like an
experimental science. Once you have an idea what is going wrong, you
modify your program and try again. If your hypothesis was correct, then
you can predict the result of the modification, and you take a step
closer to a working program. If your hypothesis was wrong, you have to
come up with a new one. As Sherlock Holmes pointed out: “When you have
eliminated the impossible, whatever remains, however improbable, must
be the truth.” (from A. Conan Doyle’s The Sign of Four).
For some people, programming and debugging are the same thing
s. That is, programming is the process of gradually debugging a program
until it does what you want. The idea is that you should always start
with a working program that does something, and make small
modifications, debugging them as you go, so that you always have a
working program. In our case you can start with a very simple animated
cartoon and make small modifications to it one by one.