1 Common Assumptions

The Glass is Half-Full

Programmers are optimists by nature. We always believe that our programs are actually going to run “as soon as I fix this one little problem” – despite the fact that, time and time again, we are proven wrong.

Odds are, if we weren’t such blind optimists, we would never actually dare to write a single line of code.

**Programmers Like to Assume … **

• Program input will be good

• Function parameters will be good

• Algorithms will behave as expected (no bugs)

What to do About Assumptions?

Two good possibilities

• Document them

• Guard them

And these are not mutually exclusive.

2 Documenting Assumptions

Preconditions

It’s common for functions to only work under certain circumstances.

• E.g., the sqrt function only works on non-negative inputs.

• A precondition is a condition that must be true before the function is called, if we expect the function to do anything reasonable.

  • Preconditions are an obligation on the caller, not on the function being called

Documenting Preconditions

• Preconditions should be documented in the function declaration.

  • All data necessary to evaluate the pre-condition must be available to the callers (otherwise they can’t be held responsible for checking it!)

    • No private data in pre-conditions!

• Example: Look at addInTimeOrder in

3 Guarding Assumptions

Suppose that

• you have written a function that has a precondition,

• you documented the precondition,

• but your function is called with illegal parameters anyway.

It’s not your fault, but what do you do?

Possible Reactions

1. Abort the program with an error message

2. Ignore it and let the program continue

3. Quietly correct the input and let the program continue.

4. Issue an error message, correct the input, and let the program continue.

Question: Which of these are legal responses?

Question: Which of these are reasonable responses?

Let’s think about that a bit…

Example

E.g., for

int BidderCollection::add (const Bidder& value)
//  Adds this bidder
//Pre: getSize() < getMaxSize()
{
  addToEnd (elements, size, value);
  return size - 1;
}

What should we do if add is called on a full collection?

Abort the program with an error message

int BidderCollection::add (const Bidder& value)
//  Adds this bidder
//Pre: getSize() < getMaxSize()
{
  if (size < MaxSize) 
    {
     addToEnd (elements, size, value);
     return size - 1;
    }
  else
    {
     cerr << "BidderCollection::add - collection is full" << endl;
     exit(1);
    }
}

• OK (but we’ll see an easier way to do this).

Ignore it and let the program continue

• Worst thing we can do

• We know that things are going badly, but we’re going to risk incorrect output, corrupted output files and databases, etc.

Quietly correct the input and let the program continue

int BidderCollection::add (const Bidder& value)
//  Adds this bidder
//Pre: getSize() < getMaxSize()
{
  if (size < MaxSize) 
    {
     addToEnd (elements, size, value);
     return size - 1;
    }
  else
    {
     elements[size-1] = value;
    }
}

• Nearly as dangerous as just letting the program run.

  • Usually cannot reasonably guess whether a given correction is safe or not

Issue an error message and let the program continue

int BidderCollection::add (const Bidder& value)
//  Adds this bidder
//Pre: getSize() < getMaxSize()
{
  if (size < MaxSize) 
    {
     addToEnd (elements, size, value);
     return size - 1;
    }
  else
    {
     cerr << "BidderCollection::add - collection is full" << endl;
     elements[size-1] = value;
    }
}

3.1 Guarding Assumptions with Assertions

assert(c); (from the header file <cassert>) tests to see if a boolean condition c is true. If not, it issues an error message and aborts the program.

• Assertions can be deactivated by compiling with the macro symbol NDEBUG defined.

  • Add #define NDEBUG to a header, or
  • Add -DNDEBUG as a g++ compiler option

• Some people argue for turning them off when compiling the “production” version of the code.

• Personally, I think that turning them off is a really bad idea.

assert() Example

    if (reservePriceMet && highestBidSoFar > 0.0)
      {
        int bidderNum = bidders.findBidder(winningBidderSoFar);
        // winningBidderSoFar should be in the list of registered bidders
        assert (bidderNum >= 0 && bidderNum < bidders.getSize());
        cout << item.getName()
             << " won by " << winningBidderSoFar
             << " for " << highestBidSoFar << endl;
        Bidder& bidder = bidders.get(bidderNum);
        bidder.setBalance (bidder.getBalance() - highestBidSoFar);
      }

Guarding Preconditions

Perhaps the most common use of assertions is in guarding pre-conditions.