Pre- and Post-Conditions

The Error and Warning Procedures

While the user of a procedure has the responsiblity for meeting its pre-conditions, computer scientists continue to debate whether procedures should check that the pre-conditions actually are met. Here, in summary, are the two arguments.

• Pre-conditions should always be checked as a safety matter; a procedure should be sufficiently robust that it will detect variances in incoming data and respond in a controlled way.

• Since meeting pre-conditions is a user's responsibility, a developer should not add complexity to a procedure by handling unnecessary cases; further, the execution time should not be increased for a responsible user just to check situations that might arise by careless users.

Actual practice tends to acknowledge both perspectives in differing contexts. More checking is done when applications are more critical. As an extreme example, in software to launch a missle or administer drugs to a patient, software may perform extensive tests of correctness before taking an action -- the cost of checking may be much less than the consequences resulting from unmet pre-conditions.

As a less extreme position, it is common to check pre-conditions once -- especially when checking is relatively easy and quick, but not to check repeatedly when the results of a check can be inferred. (More about this shortly.)

The error procedure in Chez Scheme

So far, we've been relying on the underlying implementation of Chez Scheme to detect and report such errors. Sometimes this is an adequate way of dealing with them, but in other cases one might prefer to write the procedure in such a way that it checks and enforces its preconditions before performing any operations on its arguments.

In Chez Scheme, this can be done by adding, at the beginning of the body of the procedure, an if-expression that tests the precondition and invokes a procedure named error if the condition is not met:

(define longest-on-list
  (lambda (ls)
  ;Pre-condition:  ls is non-empty list of strings
  ;Post-condition:  returns the string on ls of longest length

    ;; Check pre-conditions
    (if (or (null? ls)
            (not (list-of-strings? ls)))
        (error 'longest-on-list
               "the argument must be a non-empty list of strings"))

    ;; Find the longest string on the list.

    (if (null? (cdr ls))
        (car ls)
        (longer-string (car ls)
                       (longest-on-list (cdr ls))))))

(define list-of-strings?
  (lambda (ls)
  ;Pre-condition:  none
  ;Post-condition:  returns #t if ls is a non-empty list of strings
    (or (null? ls)
        (and (pair? ls)
             (string? (car ls))      
             (list-of-strings? (cdr ls))))))

The list-of-strings? procedure tests whether its argument is a list in which each element is a string. (In English: ls is a list of strings if it is either the empty list or a pair in which the first element is a string and the rest is a list of strings.) The definition of the longest-on-list procedure is the same as the one provided in the lab on recursion, except that the precondition is now being tested: The error procedure is invoked if either the incoming argument is empty or it is something other than a list of strings.

With this version of longest-on-list, the error messages are different:

> (longest-on-list '(3 6 7))

Error in longest-on-list: the argument must be a non-empty list of strings.
Type (debug) to enter the debugger.
> (longest-on-list '())

Error in longest-on-list: the argument must be a non-empty list of strings.
Type (debug) to enter the debugger.

The error is detected and reported before the procedure gets down to the point where it might try to apply string-length to a number or cdr to an empty list.

Husk-and-kernel programming

When developing procedures, it is often useful to include pre-condition testing in your procedures, as this can simply the task of identifying what happened when something goes wrong.

However, as noted above, the inclusion of pre-condition testing increases execution time. Of course, a single test may be relatively fast, but repeated testing can slow execution execution considerably. Since time is often a scarce resource, it makes sense to save it by skipping the test when you can prove that the precondition will be met. This often happens when you, as programmer, control the context in which the procedure is called as well as the body of the procedure itself.

For example, in the preceding definition of longest-on-list, although it is useful to test the precondition when the procedure is invoked ``from outside'' by an irresponsible caller, it is a waste of time to repeat the test of the precondition for any of the recursive calls to the procedure. At the point of the recursive call, you already know that ls is a list of strings (because you tested that precondition on the way in) and that its cdr is not empty (because the body of the procedure explicitly tests for that condition and does something other than a recursive call if it is met), so the cdr must also be a non-empty list of strings. So it's unnecessary to confirm this again at the beginning of the recursive call.

One solution to this problem is to replace the definition of longest-on-list with two separate procedures, a ``husk'' and a ``kernel.'' The husk interacts with the outside world, performs the precondition test, and launches the recursion. The kernel is supposed to be invoked only when the precondition can be proven true; its job is to perform the main work of the original procedure, as efficiently as possible:

(define longest-on-list
  (lambda (ls)
  ;Pre-condition:  ls is non-empty list of strings
  ;Post-conditions:  returns error if pre-condition is not met
                     otherwise, returns the string on ls of longest length

    ;; Check pre-conditions
    (if (or (null? ls)
            (not (list-of-strings? ls)))
        (error 'longest-on-list
               "the argument must be a non-empty list of strings"))

    ;; Find the longest string on the list.
    (longest-on-list-kernel ls)))

(define longest-on-list-kernel
  (lambda (ls)
  ;Pre-condition:  ls is non-empty list of strings
  ;Post-conditions:  returns the string on ls of longest length
    (if (null? (cdr ls))
        (car ls)
        (longer-string (car ls)
                       (longest-on-list-kernel (cdr ls))))))

In later labs, we'll see that there are a couple of ways to put the kernel back inside the husk without losing the efficiency gained by dividing the labor in this way.

Checking pre-conditions verifies that assumptions for a procedure are met. After writing code, a programmer also should provide evidence that the code is correct. Often, this means that the programmer should think carefully about how code should be tested. (While software-development companies normally have separate testing groups to check that an overall produce meets its specifications, individual programmers are responsible for checking their own code as well.)

In testing, the main goal should be to try to find all possible errors; that is, one should try to find test cases which might break the code. Note this is a different perspective than seeing if one can find many test cases that work correctly: if code works correctly for in one case, then the code may work correctly for many similar cases. Overall, one should identify and test as many types of circumstances as possible.

In identifying test cases, one useful strategy involves listing various circumstances that might occur. Consider, for example, the longest-on-list procedure described above. Since the procedure involves a search through the entire list, testing might include the following:

• The longest string is first on a list -- does the procedure check the first item appropriately?
• The longest string is last on a list -- is the last item on the list checked appropriately?
• The longest string is in the middle of a list -- are intermediate values handled correctly?
• The list contains exactly one item -- does processing handle the smallest valid list?

Each of these situations examines a different part of typical processing. More generally, before testing begins, we should identify different types of circumstances that might occur. Once these circumstances are determined, we should construct test data for each situation, so that our testing will cover a full range of possibilities.

In determining possible situations for testing, two approaches are commonly identified:

• White-Box Testing: Code is examined to determine each of the possible conditions that may arise, and tests are developed to exercise each part of the code.

• Black-Box Testing: The problem is examined to determine the logical cases that might arise. Test cases are developed without reference to details of code.

A list of potential situations together with specific test data that check each of those situations is called a test plan.