Note that I recommend that you write the documentation before you write the procedure. The six P's give you a way to think carefully about what you want the procedure to do before you think about how, and that thought can often guide you through both creation and debugging. There are different perspectives on preconditions. Some people feel that preconditions are a contract. Others feel that procedures should check their preconditions and respond appropriately.
Robust programs deal appropriately with incorrect input.
Sometimes, the appropriate response is to print an error message and crash. You can use error to do just that. If your procedure explicitly tests a precondition, I suggest that you mark the precondition as verified . In class, we'll look at how you might deal with the problem of summing the squares of the values in a list of numbers, both in terms of documentation and in terms of error messages. Good programming style dictates that we try not to do redundant work.