1. Errors Lecture 6 Hartmut Kaiser hkaiser@cct.lsu.edu

2. Abstract
When we program, we have to deal with errors. Our most basic aim is correctness, but we must deal with incomplete problem specifications, incomplete programs, and our own errors. Here, we’ll concentrate on a key area: how to deal with unexpected function arguments. We’ll also discuss techniques for finding errors in programs: debugging and testing.
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

3. Overview Kinds of errors Argument checking Error reporting
Error detection
Exceptions
Debugging
Testing
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

4. Errors
“ … I realized that from now on a large part of my life would be spent finding and correcting my own mistakes.”
Maurice Wilkes, 1949
When we write programs, errors are natural and unavoidable; the question is, how do we deal with them?
Organize software to minimize errors.
Eliminate most of the errors we made anyway.
Debugging
Testing
Make sure the remaining errors are not serious.
My guess is that avoiding, finding, and correcting errors is 95% or more of the effort for serious software development.
You can do much better for small programs.
or worse, if you’re sloppy
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

5. Your Program Should produce the desired results for all legal inputs
Should give reasonable error messages for illegal inputs
Need not worry about misbehaving hardware
Need not worry about misbehaving system software
Is allowed to terminate after finding an error
3, 4, and 5 are true for beginner’s code; often, we have to worry about those in real software.
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

6. Sources of Errors Poor specification “What’s this supposed to do?”
Incomplete programs
“but I’ll not get around to doing that until tomorrow”
Unexpected arguments
“but sqrt() isn’t supposed to be called with -1 as its argument”
Unexpected input
“but the user was supposed to input an integer”
Code that simply doesn’t do what it was supposed to do
“so fix it!”
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

7. Kinds of Errors Compile-time errors Syntax errors Type errors
Link-time errors
Run-time errors
Detected by computer (crash)
Detected by library (exceptions)
Detected by user code
Logic errors
Detected by programmer (code runs, but produces incorrect output)
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

8. Check your Inputs
Before trying to use an input value, check that it meets your expectations/requirements
Function arguments
Data from input (istream)
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

9. Bad Function Arguments
The compiler helps:
Number and types of arguments must match
int area(int length, int width) {
return length*width; }
int x1 = area(7); // error: wrong number of arguments
int x2 = area("seven", 2); // error: 1st argument has a wrong type
int x3 = area(7, 10); // ok
int x5 = area(7.5, 10); // ok, but dangerous: 7.5 truncated to 7;
// most compilers will warn you
int x = area(10, -7); // this is a difficult case:
// the types are correct,
// but the values make no sense
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

10. Bad Function Arguments
So, how about int x = area(10, -7);
Alternatives
Just don’t do that
Rarely a satisfactory answer
The caller should check
Hard to do systematically
The function should check
Return an “error value” (not general, problematic)
Set an error status indicator (not general, problematic – don’t do this)
Throw an exception
Note: sometimes we can’t change a function that handles errors in a way we do not like
Someone else wrote it and we can’t or don’t want to change their code
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

11. Bad Function Arguments
Why worry?
You want your programs to be correct
Typically the writer of a function has no control over how it is called
Writing “do it this way” in the manual (or in comments) is no solution – many people don’t read manuals
The beginning of a function is often a good place to check
Before the computation gets complicated
When to worry?
If it doesn’t make sense to test every function, test some
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

12. How to Report an Error
Return an “error value” (not general, problematic)
// return a negative value for bad input
int area(int length, int width) {
if (length <= 0 || width <= 0) return -1;
return length*width; }
So, “let the caller beware”
int z = area(x,y);
if (z < 0) error("bad area computation");
// …
Problems
What if I forget to check that return value?
For some functions there isn’t a “bad value” to return (e.g. max())
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

13. How to Report an Error
Set an error status indicator (not general, problematic, don’t!)
int errno = 0; // used to indicate errors
int area(int length, int width) {
if (length <= 0 || width <= 0) errno = 7;
return length*width; }
So, “let the caller check”
int z = area(x,y);
if (errno == 7) error("bad area computation");
// …
Problems
What if I forget to check errno?
How do I pick a value for errno that’s different from all others?
How do I deal with that error?
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

14. How to Report an Error Report an error by throwing an exception
class Bad_area {}; // a class is a user defined type
// Bad_area is a type to be used as an exception
int area(int length, int width) {
if (length <= 0 || width <= 0) throw Bad_area(); // note the ()
return length * width; }
Catch and deal with the error (e.g., in main())
try {
int z = area(x,y); // if area() doesn’t throw an exception
} // make the assignment and proceed
catch (Bad_area) { // if area() throws Bad_area(), respond
cout << "oops! Bad area calculation – fix program\n";
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

15. Exceptions Exception handling is general
You can’t forget about an exception: the program will terminate if someone doesn’t handle it (using a try … catch)
Just about every kind of error can be reported using exceptions
You still have to figure out what to do about an exception (every exception thrown in your program)
Error handling is never really simple
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

16. Out of range
Try this
vector<int> v(10); // a vector of 10 ints, each
// initialized to the default value,
// 0, referred to as v[0] .. v[9]
for (int i = 0; i != v.size(); ++i)
v[i] = i; // set values
for (int i = 0; i <= 10; ++i) // print 10 values (???)
cout << "v[" << i << "] == " << v.at(i) << endl;
vector’s operator[ ] (subscript operator) reports a bad index (its argument) by throwing a std::range_error if you compile in ‘Debug’ mode (VS only)
The default behavior can differ, use at() to guarantee checking
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

17. Exceptions – for now
For now, just use exceptions to terminate programs gracefully, like this
int main() {
try {
// … }
catch (std::out_of_range) { // out_of_range exceptions
std::cout << "oops – some vector index out of range\n";
catch (...) { // all other exceptions
std::cout << "oops – some exception\n";
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

18. How to Look for Errors
When you have written (drafted?) a program, it’ll have errors (commonly called “bugs”)
It’ll do something, but not what you expected
How do you find out what it actually does?
How do you correct it?
This process is usually called “debugging”
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

19. Debugging How not to do it // pseudo code
while (program doesn’t appear to work) {
Randomly look at the program for something
that “looks odd”.
Change it to “look better” }
Key question:
How would I know if the program actually worked correctly?
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

20. Program structure
Make the program easy to read so that you have a chance of spotting the bugs
Comment
Explain design ideas
Use meaningful names
Indent
Use a consistent layout
Your IDE tries to help (but it can’t do everything)
You are the one responsible
Break code into small functions
Try to avoid functions longer than a page
Avoid complicated code sequences
Try to avoid nested loops, nested if-statements, etc.
(But, obviously, you sometimes need those)
Use library facilities
Use consistent error handling
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

21. First Get the Program to Compile
Is every string literal terminated?
cout << "Hello, << name << '\n'; // oops!
Is every character literal terminated?
cout << "Hello, " << name << '\n; // oops!
Is every block terminated?
if (a > 0) { /* do something */
else { /* do something else */ } // oops!
Is every set of parentheses matched?
if (a // oops!
x = f(y);
The compiler generally reports this kind of error “late”
It doesn’t know you didn’t mean to close “it” later
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

22. First Get the Program to Compile
Is every name declared?
Did you include needed headers? (e.g., iostream, etc.)
Is every name declared before it’s used?
Did you spell all names correctly?
int count; /* … */ ++Count; // oops!
char ch; /* … */ Cin >> c; // double oops!
Did you terminate each expression statement with a semicolon?
x = sqrt(y) // oops!
z = x + 3;
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

23. Debugging
Carefully follow the program through the specified sequence of steps
Pretend you’re the computer executing the program
Does the output match your expectations?
If there isn’t enough output to help, add a few debug output statements
cout << "x == " << x << ", y == " << y << '\n';
Be very careful
See what the program specifies, not what you think it should say
That’s much harder to do than it sounds
for (int i = 0; 0 != month.size(); ++i) { // oops!
for (int i = 0; i <= max; ++j) { // oops! (twice)
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

24. Debugging
When you write the program, insert some checks (“sanity checks”) that variables have “reasonable values”
Function argument checks are prominent examples of this
if (number_of_elements < 0)
throw runtime_error("impossible: negative number of elements");
if (number_of_elements > largest_reasonable)
throw runtime_error("unexpectedly large number of elements");
if (x < y)
throw runtime_error("impossible: x < y");
Design these checks so that some can be left in the program even after you believe it to be correct
It’s almost always better for a program to stop than to give wrong results
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

25. Debugging Pay special attention to “end cases” (beginnings and ends)
Did you initialize every variable?
To a reasonable value
Did the function get the right arguments?
Did the function return the right value?
Did you handle the first element correctly?
The last element?
Did you handle the empty case correctly?
No elements
No input
Did you open your files correctly?
more on this later
Did you actually read that input?
Write that output?
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

26. Debugging
“If you can’t see the bug, you’re looking in the wrong place”
It’s easy to be convinced that you know what the problem is and stubbornly keep looking in the wrong place
Don’t just guess, be guided by output
Work forward through the code from a place you know is right
so what happens next? Why?
Work backwards from some bad output
how could that possibly happen?
Once you have found “the bug” carefully consider if fixing it solves the whole problem
It’s common to introduce new bugs with a “quick fix”
“I found the last bug”
is a programmer’s joke
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

27. Note
Error handling is fundamentally more difficult and messy than “ordinary code”
There is basically just one way things can work right
There are many ways that things can go wrong
The more people use a program, the better the error handling must be
If you break your own code, that’s your own problem
And you’ll learn the hard way
If your code is used by your friends, uncaught errors can cause you to lose friends
If your code is used by strangers, uncaught errors can cause serious grief
And they may not have a way of recovering
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

28. Pre-conditions What does a function require of its arguments?
Such a requirement is called a pre-condition
Sometimes, it’s a good idea to check it
// calculate area of a rectangle
int area(int length, int width) {
// length and width must be positive
if (length <= 0 || width <= 0)
throw Bad_area();
return length * width; }
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

29. Post-conditions What must be true when a function returns?
Such a requirement is called a post-condition
// calculate area of a rectangle
int area(int length, int width) {
// length and width must be positive
if (length <= 0 || width <= 0)
throw Bad_area();
// the result must be a positive int that is the area
int result = length * width;
if (result <= 0)
return result; }
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

30. Pre- and post-conditions
Always think about them
If nothing else write them as comments
Check them “where reasonable”
Check a lot when you are looking for a bug
This can be tricky
How could the post-condition for area() fail after the pre- condition succeeded (held)?
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors

31. Testing How do we test a program? Be systematic
“pecking at the keyboard” is okay for very small programs and for very initial tests, but is insufficient for real systems
Think of testing and correctness from the very start
When possible, test parts of a program in isolation
E.g., when you write a complicated function write a little program that simply calls it with a lot of arguments to see how it behaves in isolation before putting it into the real program
We’ll return to this question later
9/19/2013, Lecture 6
CSC 1254, Fall 2013, Errors