Re: Pre-condition vs. Post-condition

[g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University)]

In article <2865@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
>>Say we have a function CAPITAL which, given a country's name, returns its
>>capital city.  If the given country does not exist, an exception COUNTRY_ERROR
>>is raised.  Should the given country's presence be listed as a pre-condition
>>for this function, or should its absense (it doesn't exist) and the raising
>>of COUNTRY_ERROR be listed as a post-condition?
>>
>>I brought this question up in class today and the outcome was a split decision.
>>I think exception raising and/or handling is as valid an outcome of a function
>>or procedure as any other outcome, so I'm tempted to cover the issue in the
>>post-condition comment.  My opponents believe that a function's pre-conditions
>>should be the conditions under which it would complete "normally", that is,
>>without any exceptions being raised.
> 
> Hmmm. Interesting question. I have always taught - and thought of - pre-
> conditions as a set of "contract terms" which, if they are met, would
> obligate the function writer to write code that delivers the right results.
> From a verification point of view, I think you are correct that raising
> an exception is a _valid_ outcome of the function, and so the function has
> to be tested with cases of "bad" input to check that the exception indeed
> is raised under those conditions. If the pre- and post-conditions are used
> to drive tests (or formal verification), I agree that _explicit_ exception-
> raising by the function is a post-condition matter: it needs to be tested.
> 

Lots of stuff deleted.  

This problem raises some interesting questions:  Should pre and post conditions
define the complete functionality of a subroutine?  Should a function which has
only one returned value (in Ada) be allowed to have a compound post condition? 
(old question) How exceptional should exceptions be used? (or something like
that.)


> This argument makes sense to me from a theoretical standpoint. From a 
> practical standpoint, in describing the interface to a function, how does
> one distinguish between violations that result in a _predictable_ behavior
> and those that do not? I can see why your students may have disagreed.
> It's a confusing matter. I'm posting this to the net to provoke other
> readers to join this thread if they are interested.
> 
> Mike Feldman

On a practical (the theoretical) view the user probably should redo his
function as a procedure returning TWO values (the captial and a boolean object
SUCCESSFUL); write the usualy pre and post conditions for that procedure; then
make a functional isomorphism back to the original function.  


Actually, IMHO, if a practical intent of the function IS to guard against
wrong countries, then a procedure might be better anyway.  

-- George C. Harrison                              -----------------------
----- Professor of Computer Science                -----------------------
----- Norfolk State University                     -----------------------
----- 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
----- INTERNET:  g_harrison@vger.nsu.edu ---------------------------------