Pre-condition vs. Post-condition

Pre-condition vs. Post-condition

[Chris M. Little]

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.

I'd appreciate any insight on the issue.  E-mail please.  Thanks.

-- 
Chris Little, Graduate Asstistant	-     CML8@JAGUAR.UOFS.EDU	(VMS)
Department of Computing Sciences	-     CML8@SCRANTON.BITNET	(VMS)
University of Scranton, Pennsylvania.	-     CML8@ROBIN.CS.UOFS.EDU    (UNIX)

Re: Pre-condition vs. Post-condition

[Michael Feldman]

>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.

Failure of a caller to meet a pre-condition violates the contract between
function writer and function user, in a way that the behavior of the
function is _unpredictable_, for example the actual parameter is 
unitialized. If the "garbage" in the parameter _happens_ to constitute
an in-range value, the function delivers a "correct" answer, coincidentally.
Otherwise, an exception may be _unexpectedly_ raised (constraint_error, say).
Since the caller has violated the contract, he gets what he deserves (an
unexpected propagation of an exception). So the pre-conditions are really
saying "if you violate these, all bets are off on what this function does."

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

Re: Pre-condition vs. Post-condition

[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 ---------------------------------

Re: Pre-condition vs. Post-condition

[Joe Hollingsworth]

In article <2865@sparko.gwu.edu> mfeldman@seas.gwu.edu () 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.
....stuff deleted.....
>Mike Feldman

I'm glad you raised the point of formal verification.  I'd like to point
out how the use of exception handling complicates verification (be it
formal or informal).

Examine the following possible implementation for Pop (popping a stack).

procedure pop(s: stack)
-- this pop doesn't return the top of the stack, just discards it.
begin
   if(not empty(s)) then
      -- pop the stack
   else
      raise underflow
end pop;

The point here is that there are 2 distinct paths through the procedure
which will have to be verified with respect to the pre and post conditions
(pre and post conditions not given).  The two paths are easy to spot.

Now look at another implementation of Pop based on Booch's stack package:

procedure pop(s: stack)
-- this pop doesn't return the top of the stack, just discards it.
begin
   stack.top := stack.top - 1;
   exception
      when Constraint_Error => raise underflow
end pop;

Here there are also two paths through the procedure, but it's not so
obvious to the reader (verifier) how the path through the exception
handler gets taken.  The verifier has to realize that the variable
stack.top has been defined as Natural and that a Constraint_Error
will be raised by the run time system when trying to set it to -1.

Since the control flow in this example is not explicit, let's call
it implicit.  I believe that verifying (formally or informally) code
written using implicit control flow is harder than code using explicit
control flow.  If this point is valid, one might then believe that 
code written using implicit control flow stands a better chance of NOT
being verified correctly, especially if it is informally verified.  What's
more I also believe that using exceptions leads one toward this kind
of programming (i.e. depending on implicit control flow).

I'm a follower of many of the rules found in Kernighan & Plauger's
"The Elements of Programming Style", two of those rules reads as follows:

"Write clearly - don't be too clever."
"Say what you mean, simply and directly."

I believe that exception handling leads one to writing programs that are not
as clear as they could be (see the second example above which doesn't
say what it means simply and directly).

With respect to verification, if the verifier is mechanical, then it probably
doesn't matter if the code uses implicit or explicit control, the
verifier will be able to handle it.  But, when was the last time any of
us used a mechanical verifier on our Ada programs?  Chances are
the verifier is the person writing the code, and that person is doing it
informally.  All the more reason to "Write clearly..." and "Say what you
mean, simply and directly."

The above arguments lead me to believe that exception handling should be used
only sparingly (if at all)!

(Mike, you wanted to get a debate going on this?  The above opinions
should help!)

Joe 

Joe Hollingsworth  Computer and Information Science @ OSU
holly@cis.ohio-state.edu

Re: Pre-condition vs. Post-condition

[Marlene M. Eckert]

How about exceptions should be raised only in _EXCEPTIONAL_ 
situations?  Reaching the end-of-file or trying to POP off an
empty stack are NOT exceptional conditions.
  
I would go so far as to say an exception should never be raised after 
a system has been delivered.  Don't get me wrong, I love Ada exception
handling...  Exception Handling made my last large integration go much 
smoother than I expected. 

Any comments??

Michael Reznick
Structured Systems & Software (3S)
sss@cerf.net
----------------------------------------------------------------------
Standard disclaimer...
----------------------------------------------------------------------

Re: Pre-condition vs. Post-condition

[Michael Feldman]

In article <311@nic.cerf.net> sss@nic.cerf.net (Marlene M. Eckert) writes:
>How about exceptions should be raised only in _EXCEPTIONAL_ 
>situations?  Reaching the end-of-file or trying to POP off an
>empty stack are NOT exceptional conditions.
>  
Well, this is getting to be an interesting thread on exception-handling
philosophy. I disagree with you. A client of a stack package which 
- due to a logic bug in the client algorithm - tries to pop a stack which
turns out to be empty, is indeed committing an error. IMHO this in indeed
an exceptional situation, and raising Stack_Underflow or whatever is
quite appropriate. The client should use a Stack_Is_Empty boolean
function to test for the empty condition, but s'pose he doesn't?
IMHO _both_ entities should be exported from a stack package.
I agree that a program that tests for the empty condition by trying to
pop and then handling the exception is doing violence to exceptions.

Roughly the same is true for end-file conditions. Text_IO exports a
perfectly good function End_Of_File for this purpose. Nevertheless,
s'pose a client of Text_IO screws up and doesn't test, or tests in
the wrong place? The package should raise End_Error for this unintentional
attempt to read past EOF. As in the stack case, one should NOT write
clients that test for normal EOF by just reading and reading until the
exception is raised. Once again, that's abusive.

Here's a more obvious one:

Given TYPE Days IS (Mon, Tue, Wed, Thu, Fri, Sat, Sun);

we find Tomorrow by writing

   IF Today = Days'Last THEN 
     Tomorrow := Days'First
   ELSE
     Tomorrow := Days'Succ(Today);
   END IF;

NOT

   BEGIN
     Tomorrow := Days'Succ(Today);
   EXCEPTION
     WHEN Constraint_Error => 
       Tomorrow := Days'First;
   END;

Some bit-fiddlers have argued that the latter is slightly more efficient,
but I still think it's abusive. Monday follows Sunday EVERY WEEK. The
only thing surprising about it is that Ada doesn't allow cyclic types!

Mike Feldman

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>Some bit-fiddlers have argued that the latter is slightly more efficient,

BIT FIDDLER!?!?!? BIT FIDDLER!?!?!?!?

Stab me in the heart and TWIST THE KNIFE, why don't you?

Sheesh.

Of all the low blows over the years, this has GOT to take the cake.
I realize I made an argument based on efficiency, but I assure you
that was a momentary lapse. I've been accused of over-abstraction
before, but never bit fiddling. I HATE bits--if there was a way
to run software without hardware I'd jump at it.

I'm a software architect, software process and methodology consultant,
and OO/Ada trainer. Efficiency is about 96th on my list of concerns:
I generally tell people the way to improve performance is to bid faster
hardware, not worry about this or that register allocation word alignment
or whatever.

Bit fiddler.

Sheesh.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

Exception usage design issues (was: Pre-condition vs. Post-condition)

[John Goodenough]

Seeing all this discussion about the philosophy of exception usage reminded me
of a short position paper I wrote a few years ago on this point.  I'm posting
it here because it presents some views that haven't been stated yet, and
someone once told me that it had been helpful when they were designing a real
system.

\f

                    USING EXCEPTIONS: SOME DESIGN ISSUES

			     John B. Goodenough
		       Software Engineering Institute
	      Carnegie Mellon University, Pittsburgh, PA 15213

                             September 21, 1988


1 Summary

This paper addresses Topic 9 of the Application Software Design working
group:

     Discuss the best use of exceptions in the design of management
     information systems, their benefits and problems, including scope,
     propagation, control, and usage.

Only Ada and PL/I provide explicit language support for handling exceptions.
Since exceptions are not supported explicitly by the most commonly used
programming languages,(FORTRAN, COBOL, and C) few programmers and system
designers have experience in making effective use of this language feature.
It's easy to think of exceptions as a kind of ``add-on'' feature of a
software design, i.e., a facility whose use is left to the designers of
individual modules and routines.  In fact, exceptions are used most
effectively only if the strategy guiding their use is developed in the
earliest stages of a design.  Moreover, effective use of exceptions requires
attention throughout a design.

In this paper, I will discuss some of the questions that should be considered
by information system designers when deciding how to treat exceptions in
designs.


2 Definitions

First some definitions.  An exception situation arises when an operation is
invoked and cannot be completed in a ``normal'' fashion.  From a design
viewpoint, I think it is best to view an exception situation as a situation
that occurs when an operation is invoked and certain input predicates fail to
hold.  The invoked operation detects this failure and allows the invoker to
deal with the situation appropriately.  The advantage of identifying and
using exceptions is that it allows the effect of an operation to be extended
to cover a wider range of situations, since the invoker is given the
responsibility.

What are some examples of input predicates whose failure gives rise to an
exception situation?

   - For a POP operation of a stack or queue, an input predicate is
     ``the stack or queue has at least one element.''  An exception
     situation occurs when POP is invoked and this predicate does not
     hold.

   - For a READ operation on a file, an input predicate is ``there
     exists a record to be read.''

   - For a TABLE_LOOKUP operation, an input predicate is ``the
     sought-for value exists.''

   - For MATRIX_INVERSION, an input predicate is ``an inverse exists.''

An exception condition is signaled to the invoker of an operation when the
corresponding exception situation is detected.  A handler for the condition
specifies the invoker's response to the exception situation.

Exception situations are not always errors.  They may be boundary conditions
whose significance is known primarily to the operation's invoker.  Exceptions
serve to generalize operations (making them usable in a wider variety of
situations) because:

   - The response to an exception situation is provided by the invoker
     instead of by the operation itself.

   - An arbitrary, operation-defined response to the situation can be
     replaced by an appropriate user-defined response.


3 Design Issues

My definition of an exception situation leads to natural questions that
should be addressed during the design phase.

   - First, identify the input assertions associated with an operation,
     i.e., the assumptions and preconditions that allow the operation to
     complete in a ``normal'' manner.

   - Then evaluate each assertion, using criteria such as:

        * How easy is it for the operation's invoker to check the
          assertion before calling the operation?

        * When the check fails, is a fixed response (provided by the
          operation) always acceptable?

        * An operation's behavior may be undefined if an operation is
          invoked when an input assertion is unsatisfied.  Are the
          consequences of such behavior likely to be important?

Depending on the answers to these questions, a designer can decide whether an
exception situation should be handled by signalling an exception condition.

Given a decision to handle an exception situation, there are some other
design decisions that need to be considered:

   - Should an inquiry function be provided?

   - Should a boolean function be provided to check whether the
     exception situation will occur?

An inquiry function is called after an exception is raised and provides
additional information about the nature of the situation.  Such functions are
useful when the invoker's response to an exception situation might change
depending on specific details involved in the situation.  For example, if an
operation detects ill-formed terminal input, the most helpful response may
depend on the specific characters that were typed in.  Since an exception
handler does not, in general, have access to all the information available to
the operation that signals the exception, the needed additional information
must be provided to the invoker.  There are at least two ways of doing this:

   - If the programming language permits exceptions to be raised with
     parameters, the designer needs to decide what parameters should be
     provided.

   - If no parameters can be associated with exceptions, an inquiry
     function must be provided.

Providing an inquiry function extends the usability of an abstract data type,
but it can easily violate information hiding principles, since the details of
a particular exception situation might well reflect an implementation
approach.  Nonetheless, such functions are very useful when investigating
mysterious program behavior.  If they are not provided consistently
throughout a design, it can be very difficult to extract the needed
information by using a debugging tool.  The MULTICS operating system, written
in PL/I, was careful to provide such functions for all basic operations.  In
one case when I was using MULTICS, PL/I told me that I had encountered a
device error.  I would have been unable to diagnose the reason for the
problem if I hadn't been able to call a function returning the full status
word for the device.  Of course, such a function is device dependent, and
this is the disadvantage of such functions.

Whenever it's not too costly, it's a good idea to provide a boolean function
that checks for an exception situation.  For example, if a READ operation
will raise an exception when the end of a file is encountered, a function
should also be provided that checks for the end of file.  These functions
sometimes allow more readable programs to be written.  For example, if the
programmer is primarily interested in whether a file is at its end, it is
certainly more convenient to check this directly by calling the end-of-file
function rather than by calling the READ operation just to see if it raises
an exception!  (And if it doesn't, you need to preserve the value that was
read.)  In addition, some language constructs depend on the use of predicates
rather than exceptions.  For example, a guard in an Ada select statement is a
boolean expression.  If the value of a guard depends on the state of a file
and there is no end-of-file function, the programmer must go to considerable
trouble to obtain the correct boolean value.

Of course, it's not always appropriate to define an exception for every input
predicate.  For example, a precondition for the correct operation of a binary
search function is that the table being searched is ordered.  Checking that
the table is ordered each time the search is called would completely defeat
the purpose of the algorithm!  Here is a case where no exception should be
defined.

Similarly, it is not always appropriate to provide a function to check for an
exception situation independently of invoking the operation.  For example, a
matrix inversion operation should raise an exception when the matrix has no
inverse, but since it is almost as costly to check for this situation as to
attempt to find the inverse, it's probably not sensible to provide a function
in this case.


4 Example

As a simple example of these ideas, consider a simple function that is to
calculate the sum of a set of numbers presented in some input stream.  What
preconditions could lead to exception situations, and what inquiry functions
might be provided?  For which exception situations should corresponding
boolean functions be provided?

The preconditions could be:

   - There exists a sum (i.e., the sum does not overflow; it is
     representable).

   - The input stream is not empty.

   - The input is syntactically valid.

Possible inquiry functions and their results could be:

   - When overflow occurs, the inquiry function returns the sum just
     before the exception was raised, together with the number that was
     read.

   - When any exception occurs, an inquiry function returns how many
     numbers have been read, telling the programmer how much of the
     input stream has been processed.

   - When syntactically invalid input is read, an inquiry function can
     return the invalid string that was read.

                                 REFERENCES

Issues concerning the use of exceptions, particularly in Ada, are discussed
in some detail in pages 94-127 of Ada in Practice.(Ausnit, C. N., Cohen,
N. H., Goodenough, J. B., and Eanes, R. S, Springer-Verlag, 1985.)
-- 
John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Pre-condition vs. Post-condition

[Michael Feldman]

In article <jls.669524498@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>Some bit-fiddlers have argued that the latter is slightly more efficient,
>
>BIT FIDDLER!?!?!? BIT FIDDLER!?!?!?!?
>
>Stab me in the heart and TWIST THE KNIFE, why don't you?

Well, OK, you're not a bit fiddler. It's just that in discussing design-
oriented questions like pre- and post- conditions, appropriate design 
with exceptions, and the like, too many folks STILL jump too quickly into
micro-efficiency matters and questions of how compilers implement exceptions.
This gives me a sense of deja-vu from the early days of structured
programming etc., when people argued that go-to's were faster
than loops and procedures, and self-modifying code was even faster than that.
So what? We all know that computers and compilers both get faster over time.

Actually, I wrote the "bit fiddler" comment even before I read your note,
which was several notes later in my news reader. I chuckled when I read
your note, because I knew SOMEONE would raise the issue.

Performance issues are NOT unimportant - even this fuzzyheaded professor
would agree with that - but I think discussions of marginal gains or losses
in efficiency, traded off against more important design matters, just
muddy the waters. 

Sorry, Jim .. I didn't even know your note was out there...nothing personal.

Mike

Re: Pre-condition vs. Post-condition

[Charles H. Sampson]

In article <311@nic.cerf.net> sss@nic.cerf.net (Marlene M. Eckert) writes:
>How about exceptions should be raised only in _EXCEPTIONAL_ 
>situations?  Reaching the end-of-file or trying to POP off an
>empty stack are NOT exceptional conditions.

     O. K., but that just pushes the issue off to deciding what the word
_exceptional_ means.  The definition I prefer to use is: "An exceptional
condition is one that occurs infrequently or unexpectedly."  (Not original,
but I forgot whom I stole it from.  I think it was John Barnes.)  When
teaching Ada, immediately after giving that definition I point out to the
students that it does not require all exceptional conditions to be handled
by exceptions.

     What's happening here is that we're in an area where a lot of design
decisions have to be made.  I'm not sure that there is a rule that can be
applied to all cases and I am sure that if there is one we haven't found
it yet.  Unlike Mike Feldman, I have no philosophical problem with using
End_error to detect end-of-file or stack underflow to determine that the
stack is now empty, both satisfying the _infrequent_ criterion.  (I doubt
that I would ever use the latter myself, but my reasons are more esthetic
than anything else.)  Before I would condemn these uses in any particular
situation, I would want to hear the reasons for them.

     This has been an interesting thread to follow as we grapple with
this problem.  I particularly appreciate the fact that very few dogmatic
positions have been put forward.

                              Charlie

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>When teaching Ada, immediately after giving that definition I point out to the
>students that it does not require all exceptional conditions to be handled
>by exceptions.

Exactly. Some are better handled by status parameters, or status fields
in abstract data types, or whatever.

>     What's happening here is that we're in an area where a lot of design
>decisions have to be made.  I'm not sure that there is a rule that can be
>applied to all cases and I am sure that if there is one we haven't found
>it yet.

Exactly. Although I do think there are heuristics, such as the infrequency
criterion. For example, I have no problem with blowing up on underflow
instead of pre-checking it. But I wouldn't use an exception to implement
a cyclic type, since the whole point of a cyclic type is that it will
be cycled through, so using the exception on 'succ is poor form.

In short, I use exceptions whenever their being raised would signal to
someone in a debugger that something undesirable has occurred. Underflowing
a stack is undesirable. Cycling a type is normal, so trapping that in
a debugger would confuse the hell out of the maintenance programmer (it
brings in the oxymoronic notion of a "normal exception"!).
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>Reaching the end-of-file or trying to POP off an
>empty stack are NOT exceptional conditions.

How to you justify this? Exceptions protect clients from incorrect
algorithmic implementation. If a client attempts to read past end of
file or pop past empty stack, it should be notified of the fact,
since the client is in error. Other mechanisms (e.g. status flags)
must be checked by the client to be effective (polling model), whereas
exceptions cannot be overlooked (interrupt model). Thus, exceptions
are more fail-safe.

You also say that you don't think an exception should ever be raised
after a system is delivered. I don't see how you can meet this constraint.
For example, consider interaction with a user, a la Enumeration_Io.
If the user enters bogus data--which you have no control over from
within the program--an exception will be raised. This is not only
unavoidable, but seems desirable to me.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>procedure pop(s: stack)
>begin
>   if(not empty(s)) then
>      -- pop the stack
>   else
>      raise underflow
>end pop;

>procedure pop(s: stack)
>begin
>   stack.top := stack.top - 1;
>   exception
>      when Constraint_Error => raise underflow
>end pop;

Note that in the second case the procedure is faster, since it doesn't
have to do the check first. Not only is it faster, it is safer, since
without using tasks you cannot guarantee that between the time you
checked and the time you popped it hadn't been popped elsewhere. For
both of these reasons, I'd say the second version is far better than
the first version, and that the original poster's thesis that exceptions
should be used rarely if ever has been contradicted by the very examples
provided to support his/her case!

P.S. You need an "end if" in the first example.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

Re: Pre-condition vs. Post-condition

[Joe Hollingsworth]

In article <jls.669368339@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>procedure pop(s: stack)
>>begin
>>   if(not empty(s)) then
>>      -- pop the stack
>>   else
>>      raise underflow
     end if;
>>end pop;
>
>>procedure pop(s: stack)
>>begin
>>   stack.top := stack.top - 1;
>>   exception
>>      when Constraint_Error => raise underflow
>>end pop;
>
>Note that in the second case the procedure is faster, since it doesn't
>have to do the check first. 

I figured I'd see this argument, but I don't buy it.

1) Refering back to Kernighan & Plauger's "The Elements of Programming
Style," I'll quote another rule:

"Write clearly - don't sacrifice clarity for 'efficiency'."


2) Ok, so you think that the second version of Pop is faster
because it is not doing the test.  Well there may not be an explicit 
test, but there sure has to be an implicit one.  The compiler has
to generate code to test to see if a constraint error needs to be
raised, i.e. there is run time checking going on here.  And you 
sure can't use the SUPRESS pragma to get rid of it.

There is testing going on here, either you see it
explicitly in the code, or it gets done for you by run time checks.


>Not only is it faster, it is safer, since
>without using tasks you cannot guarantee that between the time you
>checked and the time you popped it hadn't been popped elsewhere. 

The examples given were for the sequential world, there was no
mention in the original posting or my follow up about tasking.

>For both of these reasons, I'd say the second version is far better than
>the first version, and that the original poster's thesis that exceptions
>should be used rarely if ever has been contradicted by the very examples
>provided to support his/her case!

I don't think the follow up poster has really come up a with good
case.  His/her case is mainly based on efficiency concerns,
which obviously doesn't hold since run time checks have to be performed.
And, the follow up poster's far better version is still not as clear
as the first version.


>P.S. You need an "end if" in the first example.
Thank you, I've edited the above example to include "end if."


Joe 
holly@cis.ohio-state.edu

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>1) Refering back to Kernighan & Plauger's "The Elements of Programming
>Style," I'll quote another rule:

>"Write clearly - don't sacrifice clarity for 'efficiency'."

Is this Kernighan of Kernighan & Ritchie? (If so, he doesn't follow
his own advice.)

>2) Ok, so you think that the second version of Pop is faster
>because it is not doing the test.  Well there may not be an explicit 
>test, but there sure has to be an implicit one.  The compiler has
>to generate code to test to see if a constraint error needs to be
>raised, i.e. there is run time checking going on here.

Yes, but the checking doesn't have to involve the overhead of a context
switch, as is required in your version with the call to another
subprogram. So my version is still faster, even with the checking.

>>Not only is it faster, it is safer, since
>>without using tasks you cannot guarantee that between the time you
>>checked and the time you popped it hadn't been popped elsewhere. 

>The examples given were for the sequential world, there was no
>mention in the original posting or my follow up about tasking.

Yeah, but if you do it right the first time, migrating to the
parallel world isn't a maintenance nightmare.

>I don't think the follow up poster has really come up a with good
>case.  His/her case is mainly based on efficiency concerns,

Well, I didn't make the case, but I actually think the version with
the exception is at least as easy to understand as the first version.
In this particular case the distinction is not as great, but consider
the classic "if/then" checking that is performed in languages without
exceptions:

      begin
	if some_precondition and then
           some_other_precondition and then
           yet_another_precondition then
              do_what_you_really_wanted_to_do;
        end if;
      end;

Contrast this to the exception version:
     
      begin
        do_what_you_really_wanted_to_do;
      exception
        when this_problem_occurs =>
          take_corrective_action;
        when that_problem_occurs =>
          take_other_corrective_action;
      end;

I argue that it is far easier in the exception case to figure out
what is supposed to happen, and that the reader can skip all the
error handling/checking stuff if he/she is just interested in the
main control flow. I've seen code written with so much precondition
checking that finding the actual statement that did anything was like
finding a needle in a haystack. With exceptions I don't have this
problem.

Furthermore, consider the use of procedures that raise exceptions
with the intent that they express the preconditions required:

      procedure assert_condition_valid (...) is
      begin
        if not some_precondition then
          raise this_problem_occurs;
      end assert_condition_valid;

      procedure assert_another_condition_valid (...) is... -- Similar.

      begin
        assert_condition_valid (...);
        assert_another_condition_valid (...);
        do_what_you_really_wanted_to_do;
      exception
        when this_problem_occurs =>
          take_corrective_action;
        when that_problem_occurs =>
          take_other_corrective_action;
      end;

Now in this case, I not only can find what is really being done,
I can also find out what the preconditions are, all without getting
snarled up in N levels of if-then checking. It reads well, it is
easy to maintain, and it depends on exceptions.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

Re: Explicit vs implicit checks (was Pre-condition vs. Post-condition)

[Scott Carter]

In article <98063@tut.cis.ohio-state.edu> Joe Hollingsworth <holly@cis.ohio-state.edu> writes:
>In article <jls.669368339@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>[ use built-in checking via CONSTRAINT_ERROR rather than explicit test ]
>>Note that in the second case the procedure is faster, since it doesn't
>>have to do the check first. 
>
>I figured I'd see this argument, but I don't buy it.
>
>1) Refering back to Kernighan & Plauger's "The Elements of Programming
>Style," I'll quote another rule:
>
>"Write clearly - don't sacrifice clarity for 'efficiency'."

" - at first, until you find the real cpu burners [if they are localized].
Recode them for efficiency (document it!), so you have more slop to make most
of the code clearer and more maintainable."
POP is an example of a system utility for which the tradeoffs push more for
efficiency than in most of the code (maybe).
>
>
>2) Ok, so you think that the second version of Pop is faster
>because it is not doing the test.  Well there may not be an explicit 
>test, but there sure has to be an implicit one.  The compiler has
>to generate code to test to see if a constraint error needs to be
>raised, i.e. there is run time checking going on here.  And you 
>sure can't use the SUPRESS pragma to get rid of it.

Don't be so sure about this, or assume that the check has the anywhere
near the same cost as the explicit test.  A constraint test for < 0 is
a single instruction in some machines (e.g. TBNDU on the 88000, or
on any machine which has a trap on bit instruction), and further
that instruction has more slop as far as where in the canonical order
it must go compared to the explicit test.

A really snazzy compiler which is inlining Is_empty() might reduce the
explicit check cost down to about three cycles (and introduce a block
boundary), but we just aren't there yet.
>
>Joe 
>holly@cis.ohio-state.edu

Scott Carter - McDonnell Douglas Electronic Systems Company
carter%csvax.decnet@mdcgwy.mdc.com (preferred and faster) - or -
carters@ajpo.sei.cmu.edu		 (714)-896-3097
The opinions expressed herein are solely those of the author, and are not
necessarily those of McDonnell Douglas.

Re: Pre-condition vs. Post-condition

[Brad Balfour]

In article <jls.669368339@rutabaga>
jls@rutabaga.Rational.COM (Jim Showalter) writes:
>>procedure pop(s: stack)
>>begin
>>   if(not empty(s)) then
>>      -- pop the stack
>>   else
>>      raise underflow
>>end pop;
>>procedure pop(s: stack)
>>begin
>>   stack.top := stack.top - 1;
>>   exception
>>      when Constraint_Error => raise underflow
>>end pop;
>Note that in the second case the procedure is faster, since it doesn't
>have to do the check first. Not only is it faster, it is safer, since
>without using tasks you cannot guarantee that between the time you
>checked and the time you popped it hadn't been popped elsewhere. For
>both of these reasons, I'd say the second version is far better than
>the first version, and that the original poster's thesis that exceptions
>should be used rarely if ever has been contradicted by the very examples
>provided to support his/her case!

   It should be kept in mind, however, that the first example will always
produce correct results (except in the presence of tasks where it should
be replaced with a concurrent component), but that the second example breaks
in the presence of a "pragma supress". However, on most compilers, it is
not necessary to change the code to get this effect. Instead, all one has
to do is add a switch to the compiler run to turn off the constraint checks.
Then, push will trash memory randomly and pop will return garbage rather
than raise underlfow.

   Also, the second example is not safe in the presence of multiple tasks.
It is possible for a second thread of control to be changing the contents of
the stack at the same time as the first so that between the read of
stack.top and the computation of the -1 and then the assignment there
are plenty of opportunities of the push to change (and write to) stack.top.
It is a mistake to assume that the line "stack.top := stack.top - 1;" is a
single atomic assignment.




Brad Balfour
EVB Software Engineering, Inc.
brad@terminus.umd.edu

Re: Pre-condition vs. Post-condition

[Mike Gilbert]

>>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?
>>
>> ...
>
>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.
> ...
>Failure of a caller to meet a pre-condition violates the contract between
>function writer and function user, in a way that the behavior of the
>function is _unpredictable_, for example the actual parameter is 
>unitialized. If the "garbage" in the parameter _happens_ to constitute
>an in-range value, the function delivers a "correct" answer, coincidentally.
>Otherwise, an exception may be _unexpectedly_ raised (constraint_error, say).
>Since the caller has violated the contract, he gets what he deserves (an
>unexpected propagation of an exception). So the pre-conditions are really
>saying "if you violate these, all bets are off on what this function does."
>
>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?
>
>Mike Feldman

I agree with Mike Feldman's description of a function's pre-conditions as a
contract, which, if satisfied, will cause the function to produce the
documented post-conditions, and, if violated, will produce an _unpredictable_
result.

Given this point of view, if a function guarantees to raise a specific
exception under certain pre-defined conditions, then the raising of that
exception must be considered to be part of the contract.  Because of the
guarantee of an exception, this case is very different from a function's
unpredictable behavior if preconditions are violated.

Thus, to answer the original question, the non-existence of a country causing
COUNTRY_ERROR to be raised should be listed as a post-condition.

If COUNTRY_ERROR is a post-condition, then the programmer has several options
for how to handle the possible COUNTRY_ERROR exception in the calling context:

	a If the programmer can guarantee that only valid countries will be
	  passed to CAPITAL, then, by the terms of the post-condition, the 
	  function will never raise COUNTRY_ERROR, and the calling context
	  doesn't have to allow for it.

	b If the programmer can't absolutely guarantee that the country name
	  is valid, but he doesn't expect to pass an invalid one, then the
	  choice of whether the calling context should handle COUNTRY_ERROR
	  depends on how robust the programmer wishes to make the program.

	  (For example, the country name could be generated by another function
	  which has not been formally verified but it believed to generate
	  correct output.)

	c If the programmer has no idea whether the country name is valid, then
	  the calling context had better handle COUNTRY_ERROR.  (For example,
	  the country name could be read as input from a user.)

Contrast these options with an alternate specification of CAPITAL in which the
country name must be valid as a pre-conditon, and thus an invalid country name
violates the function's contract.  With this specification, the function
CAPITAL will be _unpredictable_ if passed an invalid country name.  That is,
CAPITAL _could_ raise COUNTRY_ERROR, it _could_ raise any other exception, it
_could_ always return "SHANGRI-LA", it _could_ go into a loop, etc. etc.

So, if COUNTRY_ERROR is not a possible post-condition, then options "b" and
"c" above are not possible, because the programmer can't count on COUNTRY_ERROR
being raised.

What this all comes down to is that the post-conditions are what a function's
user can _count on_ given input that satisfies the pre-conditions.  Thus, since
the original question stated that COUNTRY_ERROR _is raised_ for a non-existent
country, then that specific exception should be listed as a post-condition.

Alternatively, if the original question had said something like "we've
currently implemented CAPITAL to raise COUNTRY_ERROR if the input country
doesn't exist, but we don't want to promise that it will always do so," then
users of CAPITAL would _not_ be able to count on that behavior, and then the
appropriate specification would be a pre-condition that the country must exist.

BTW, this is a distinction with a great deal of practical importance.  Many
large integrated software systems (e.g., a complex database package modified to
support distributed data by using a commercial network package) develop errors
because the integrator counts on behavior that a software package _currently_
exhibits (esp. under unusual circumstances), but that the developer never
intended to _guarantee_.  Then, when the next release of the software package
comes out, with different behavior under those circumstances, the integrated
system fails.

Mike Gilbert
Software Leverage

Pre-condition vs. Post-condition

["Norman H. Cohen"]

For exceptions raised by predefined basic operations, it is generally
impossible to write a precondition guaranteeing that the exception WILL
be raised.*  In such cases it is clearly appropriate to incorporate in
the precondition sufficient conditions to guarantee that no predefined
exception** will be raised.

For programmer-defined exceptions raised under predictable circumstances,
it is reasonable to incorporate in formal specifications the conditions
under which a subprogram completes normally, the circumstances under
which such exceptions are raised, and the effect on the program state
in each case.  The approach I've adopted in developing proof rules for
Ada is to assume a separate precondition/postcondition pair for each such
case:

   function CAPITAL (COUNTRY: STRING) return STRING;

   -- Let Country_Map be the mapping { "USA" -> "Washington",
   -- "Mongolia" -> "Ulan Bator", ... }.

   -- Precondition for normal completion:
   --    COUNTRY in domain Country_Map
   -- Postcondition for normal completion:
   --    function_result = Country_Map(COUNTRY)
   --
   -- Precondition for completion with COUNTRY_ERROR raised:
   --    COUNTRY not in domain Country_Map
   -- Postcondition for completion with COUNTRY_ERROR raised:
   --    TRUE  [no change of state]

It is certainly possible to incorporate all this in a postcondition:

   -- Precondition: TRUE
   -- Postcondition:
   --      (    COUNTRY in domain Country_Map
   --       and exception_raised=none
   --       and function_result=Country_Map(COUNTRY))
   --   or (    COUNTRY not in domain Country_Map
   --       and exception_raised=COUNTRY_ERROR)

However, I find this presentation more obscure for the human reader.
The first approach more naturally decomposes the behavior of the function
into separate cases of interest.  For mechanical program analysis (e.g.
for the generation of verification conditions) the first approach is also
clearly preferable, because it allows proof rules to refer to the
exception status at the end of a statement.  For example, if Pre(S,P,E)
is the precondition for statement S to complete with postcondition P and
exception status E, then the proof rule for a sequence of two statements
is:

  (1) Pre(S1;S2, P, normal) = Pre(S1, Pre(S2, P, normal), normal)

  (2) If E is the raising of some exception,
         Pre(S1;S2, P, E) =
            Pre(S1, P, E) or Pre(S1, Pre(S2, P, E), normal)

(In the exception-raising case, case (2), the left operand of "or"
corresponds to the case where S1 raises the exception and the right
operand corresponds to the case where S1 completes normally and then
S2 raises the exception.)

----------

*-Among the reasons for this are the liberty provided by RM 4.5.7(7) to
  ignore real overflow, by RM 11.6(6) to use a wider type for computation
  of intermediate results, and by RM 11.6(7) to delete an operation whose
  "only possible effect is to propagate a predefined exception."  Also
  there are cases in which DIFFERENT exceptions may be raised for
  implementation-dependent reasons, such as the order in which
  subexpressions are evaluated or an implementation's adherence to
  nonbinding interpretation AI-00387, which recommends the raising of
  CONSTRAINT_ERROR wherever the  RM calls for NUMERIC_ERROR to be raised.

**-This really means "no predefined exception other than STORAGE_ERROR
   and IO_EXCEPTIONS.DEVICE_ERROR."  These two exceptions occur for
   reasons that cannot be expressed in terms of the abstract program
   state.  The raising of one of these exceptions is best viewed as an
   unpredictable event that causes the underlying abstract machine to
   break.  It is possible to factor the possibility of such unpredictable
   events into a formal proof of program behavior, but a simpler and
   equally useful approach is to reason about program behavior under the
   assumption that such events will not occur and to prominently
   document the fact that this assumption has been made.

Re: Pre-condition vs. Post-condition

[stt]

Re: Should documentation on exception be preconditions or postconditions

This is pretty much of a style issue in my view, but
I much prefer Norm Cohen's approach for general readability.
That is, document the preconditions for normal action,
and then document the result of violating the preconditions.

I don't see why it really matters whether the exception is raised
explicitly or implicitly, or whether it is a predefined or user-defined
exception, for in Ada, the nearly universal result of violating preconditions 
is an exception, whether you state it or not.

Seeing exceptions as the result of violating preconditions emphasizes
their "exceptional" nature, and properly discourages using
exceptions as a kind of "status code."  A good rule (subject to the
usual exceptions that prove it!) is that any exception raised at 
run-time represents a program bug or an external failure, and the only 
reason to have user-defined exceptions is to provide better diagnostics
in post-mortem debugging of what are essentially unrecoverable errors.

Exceptions might trigger recovery, but probably only at a high level
(e.g., in an interactive program, they would flush the current
activity and reprompt the human operator; in a fault-tolerant system
they might cause the failing task to be decommissioned, or reset
and reelaborated.)

I realize this is a pretty extreme view of exceptions, namely that
they are primarily a debugging tool, not a programming tool, but
it is consistent with the "extreme prejudice" for efficient non-exceptional
execution speed over exception-handling speed.

Another implication of this view of exceptions is that surrounding
a single subprogram call with an exception handler is generally a bad
idea, since it implies that an exceptional condition is in fact
expected to happen!  Further, it implies that design rules stating that
undocumented exceptions should never be propagated are possibly misguided,
since handling "others" and raising some catch-all exception
is throwing away information which may be critical to post-mortem debugging.

Of course, once a subsystem gets to the point of being "fully" debugged,
and is being reused more and more, all exceptions which can be
propagated should be documented, though it may still be more appropriate
to document certain exceptions on a subsystem-wide basis, rather
than trying to identify each individual subprogram which could propagate them.
The exception handler attempting the recovery (if any), probably does
not "know" which particular subprogram call failed anyway, and it
may be more useful to know what is a reasonable recovery strategy
(e.g., how to "reset" the subsystem so as to allow clients to continue
to use it), than to know exactly which subprograms can cause the
subsystem to enter its exceptional state.

Therefore, if an exception is intended to be used for recovery
rather than simply debugging, the most important thing is that
the particular exception raised identifies which subsystem failed,
in what error state (if any) it is now, and what sort of reset
operation is appropriate.  If the exception
simply indicates that a bad parameter was passed in somewhere,
there is probably no obvious recovery strategy other than to
take two aspirin and fire up the source-level debugger in the morning...

S. Tucker Taft    stt@inmet.inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

Re: Pre-condition vs. Post-condition

[Arthur Evans]

Tucker Taft (stt@inmet.inmet.com) states that, in general, exceptions
should be used only for serious errors, and that it is rarely proper to
provide local handling.  I disagree,

In many cases, a programming is continually processing data, and (as
others have already remarked) it is almost as hard to determine in
advance if the data are flawed as it is to do the processing.  Examples:

  - An aplication is processing radar data.  The code might determine
    that a plane has moved 100 miles since the last report a few
    milliseconds ago, or changed altitude by 4000 feet, both impossible.
    Probably the problem is noise in the returned radar data, and the
    best way to deal with it is to raise a BAD_RADAR_DATA exception.
    The calling code can note the problem and ignore the data, if the
    problem is infrequent. It might report frequent errors in a trouble
    report.  In any case, though, the code processing the data can best
    serve the application by just saying (in effect), "These data are no
    good.  Do something about the problem."

  - Consider reading a text file in which each line contains formatted
    data.  The caller would check for EOF before calling the routine
    which reads the next line and processes it.  Again, invalid data
    might be reported by a BAD_DATA exception.  However, a bad input
    file might be manifested in the processing code by an unexpected EOF
    -- a line with missing trailing fields or a missing line-terminator.
    The data processing routine would probably find it most convenient
    to catch the EOF exception and reflect it to the caller as BAD_DATA.
    We have here a mixture of checking for the EOF by the caller, for
    whom it is an expected event, and catching an EOF exception in the
    line processor, for whom it represents incorrect data.

I think most dogmatic statements about how exceptions should be used
turn out to have so many exceptions as to be useless.  (Sorry about
that.)  Exceptions represent yet another tool in the hands of the
application designer; as with other tools, they must be used with care
and taste.

Art Evans

Re: Pre-condition vs. Post-condition

[Michael Feldman]

In article <23141@as0c.sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) writes:
>Tucker Taft (stt@inmet.inmet.com) states that, in general, exceptions
>should be used only for serious errors, and that it is rarely proper to
>provide local handling.  I disagree,
>
 ...lots of good stuff deleted
>
>I think most dogmatic statements about how exceptions should be used
>turn out to have so many exceptions as to be useless.  (Sorry about
>that.)  Exceptions represent yet another tool in the hands of the
>application designer; as with other tools, they must be used with care
>and taste.

I couldn't agree more. On the other hand, that there is no much discussion
and controversy about the proper use of exceptions - as there always is
about any language feature - testifies to the value of threads like this
on the net. As is the case with all tools, different people and different
projects have differing ideas about what constitutes "care" and "taste."
In the end, a consistent project-level convention about exceptions - a
well-thought out and careful design - will of course be the best policy.

This thread started with a discussion of pre- and post-conditions, to which
I'd like to return. It seems that we are using two different definitions
of preconditions. One is
(1) "A precondition is my requirement that must be met by the client, and my
 program can detect whether or not it is met."

The other is
(2) "A precondition is my requirement that must be met by the client, and my
 program CANNOT ALWAYS detect whether or not it is met."

The nastiest precondition is the one that requires that IN parameters be
initialized. This is an implicit precondition on ALL subprograms - indeed,
on all expressions - that CANNOT be tested reliably. We say - glibly -
that an uninitialized variable contains "garbage." But garbage is still
a bit pattern, AND THE BIT PATTERN MAY HAPPEN TO LIE IN THE RANGE OF
THE VARIABLE. If it does, there's no way to raise an exception on it.

In some recent discussions with folks close to Ada9x, I have discovered that
one of the proposals is to allow default initial values for all types and
subtypes. As you know, Ada83 allows default initial values only for objects,
not for types, except for fields in a record. It has come to my attention
that this is a controversial proposal; it's not clear if it will survive
review. 

If Ada allowed default initial values for all types and subtypes, e.g.

  SUBTYPE Little IS Integer RANGE -100..100 := 0;

or even

  TYPE Vector IS ARRAY (IndexType RANGE <>) OF Integer := (OTHERS => 0);

it would be much easier for projects to require that all project types be
initialized, which would greatly simplify design, since that nasty
precondition could be met globally for the whole project. (Of course
Ada could not check whether the project rule was being followed, but at
least the humans could...)

I can't think of anything that would make this harder to implement than
default _object_ initialization, and therefore it's a fairly small change
with a big potential payoff.

If you agree that default initialization of types is an important
feature for Ada9x, write to ada9x@ajpo.sei.cmu.edu about it. 

Mike Feldman

Re: Pre-condition vs. Post-condition

[Jim Showalter]

I was one of the submitters to 9x of the proposal that all types
have default initialization. This seems so obviously right I
can't see why it wouldn't survive review. Why should records
be singled out for special treatment?--it's one of those annoying
"gotchas" that piss people off when they're trying to learn the
language. I'm tired of seeing the user-view of the language--the
only one the user cares about--distorted by concerns for the language
implementers. Compiler writers are SUPPOSED to have a hard job so
that the user community has an easy job--consider the relative
percentages of time saved! One week of additional compiler writer
time is probably worth 50 years of additional programmer time.

An even more radical proposal would be to introduce constructors,
a la C++.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."

Re: Pre-condition vs. Post-condition

[Richard A. O'Keefe]

In article <jls.669961889@rutabaga>, jls@rutabaga.Rational.COM (Jim Showalter) writes:
> I was one of the submitters to 9x of the proposal that all types
> have default initialization. This seems so obviously right I
> can't see why it wouldn't survive review. Why should records
> be singled out for special treatment?

It is obviously a good idea to make the language consistent with itself.
I must admit, though, that I really like Dijkstra's notation, in which
it is simply impossible to have an uninitialised variable, the language
(and the array data structure) being designed that every "location" has
to be initialised explicitly before it can come into existence.  I
recently spent rather more time than I wanted to helping someone fix a
C program.  We eventually discovered that an initialisation routine that
had the job of allocating a bunch of arrays was being called BEFORE the
global variables with the desired array sizes were initialised.  Now C
has this helpful little rule that global variables are initialised to
0 (0.0, NIL, ASCII.NUL, FALSE, or whatever the equivalent happens to be).
Precisely *because* the variables were initialised to a "sensible" value
the error was unexpectedly hard to detect.

I would rather see features that help people detect or avoid the error
of using an uninitialised variable rather than features which define
the problem away.  For example, if arrays with fill pointers were a
standard part of the language (perhaps defined as a standard package),
then we'd be close enough to Dijkstra's arrays to get some of the
protection without being too far from the kind of array already present.

Don't expect default initial values for types to be an unmixed blessing.

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.

Re: Pre-condition vs. Post-condition

[Michael Feldman]

In article <5070@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>
>global variables with the desired array sizes were initialised.  Now C
>has this helpful little rule that global variables are initialised to
>0 (0.0, NIL, ASCII.NUL, FALSE, or whatever the equivalent happens to be).
>Precisely *because* the variables were initialised to a "sensible" value
>the error was unexpectedly hard to detect.

I don't think the _compiler_ (or the standard) should micro-manage what
should be a programmer's responsibility, namely determining, type by type,
what a "sensible" value means.
>
>Don't expect default initial values for types to be an unmixed blessing.
>
Perhaps we have a terminological problem here. By "default initial value"
we do _not_ mean "the compiler determines the value." We _do_ mean "the
programmer has the option of specifying the initializing value, and
all declared objects then have this value when they are elaborated."
This is only inconsistently possible in Ada83. 

If if we wanted the compiler to do it, things are easier said than done.
Given things like range constraints, etc., which C doesn't have to
worry about, it could be messy for the compiler to determine what the
initial value should be. E.g. 0 isn't a sensible initial value for
a Positive subtype. Perhaps Type'First would make sense, but I
still think this would micro-manage what should be a project choice.
Give the programmer the option.

Taking it a step further, the Ada9x standard _could_ REQUIRE that the
programmer give all types default initial values. I favor this;
I think it corresponds to the Dijkstra notation you were referring to.
Going that far may be controversial; I'd settle for a consistent rule
_allowing_ the programmer to do it.

Mike Feldman

Re: Pre-condition vs. Post-condition

[Richard A. O'Keefe]

In article <2929@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
> In article <5070@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >Don't expect default initial values for types to be an unmixed blessing.

> Perhaps we have a terminological problem here. By "default initial value"
> we do _not_ mean "the compiler determines the value." We _do_ mean "the
> programmer has the option of specifying the initializing value, and
> all declared objects then have this value when they are elaborated."
> This is only inconsistently possible in Ada83. 

No, we have no terminological problem here.  I understood quite clearly
what was intended.  For heaven's sake, we were shown an *example*.  We
both agree that a compile can't be expected to pick a sensible "default"
value for a type.  Why should anyone expect the designre of a package to
be able to pick a sensible default value either?  The whole point of
re-usable components is that you don't know _how_ your component is to
be misused.

Perhaps I have completely misunderstood the point of default values for
fields of records.  I thought that this, like default values for
omitted parameters, was a dodge to help people cope with the problem
where there is
	-- a package P providing a record type or procedure, and
	-- a package U using that record type or procedure
and package P is updated to include extra fields in the record type
or procedure, and it may not be practical to update the source of
package U.  (In fact, U may be a customer who won't let you anywhere
near their source.)  In this practically important but conceptually
limited case, the package provider _can_ determine sensible default
values: "those values which make the new version of the software
act just like the old version".

If I've understood correctly, then default initialisation of fields
and arguments makes the most sense for things where package U
*couldn't* have initialised those fields or parameters because
they didn't exist in the previous version of the software.

Now consider the kinds of problems that can arise with default
initialisations, *where the package user knows what the default is*.
Suppose, for argument's sake, that there is a subtype T of integer
with default value 1.  Suppose further that a user of that type wants
a variable initialised to that value.  In Ada83, you *have* to
initialise the variable *explicitly*, you had to write X: T := 1;
But when you *know* that T is initialised by default to 1, you know
that exactly the same effect can be obtained by writing X: T;
Ah, but if the providing package is updated, they do _not_ have the
same effect.  If the package changes so that T's default value is 0,
then X: T := 1; still initialises X to 1, while X: T; will initialise
X to 0.

So there is a temptation here to depend on something you perhaps
ought not to.  One thing which would reduce this temptation would
be to set things up so that a type or subtype can be specified in
a package specification and its default value in the package body.
Something along the lines of
	package FOO is
	    subtype BAZ is INTEGER range -10 .. 10 := deferred;
	    ...
	end FOO;
	...
	package body FOO is
	    subtype BAZ := BAZ'LAST:
	    ...
	end FOO:

> Taking it a step further, the Ada9x standard _could_ REQUIRE that the
> programmer give all types default initial values. I favor this;
> I think it corresponds to the Dijkstra notation you were referring to.

No it does not, not at all, no way!  It is the direct opposite!
Dijkstra's notation leaves the programmer with the obligation of
initialising every variable explicitly.  The point is that this
is defined so simply that it is *easy* for a compiler to detect.
There is no particular reason to expect that two variables of the
same type should be initialised to the same value.  Requiring that
every type be given a default initial value is what I call
"defining the problem away".  The problem of variables which the
programmer has failed to give the appropriate value _remains_,
it just isn't _called_ "being uninitialised" any more.  (It might
be called "the problem of variables which are implicitly
initialised to the wrong value".)

By the way, I never said that the *compiler* should bear all (or even
any) of the responsibility for detecting uninitialised variables.  It
is quite possible to have a debugger or interpreter that does this.
*Requiring* all types to have default initial values would make it
extremely hard, if not impossible, for such a tool to work.  _Allow_
programmer-specified defaults for programmer-defined types if you
wish (it doesn't let you do anything you couldn't do before, I think;
you could always have used records with one component).  But please
don't make a "Saber-Ada" impossible.

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.

Re: Pre-condition vs. Post-condition

[Michael Feldman]

O'Keefe's posting gave such a good discussion of the issues that there's not
much to add, except the following:

The whole thread started with preconditions. I think Ada has a chance to
make life a whole lot easier by making it _possible_ to initialize all
types with default initial values, consistently. I am not interested in
having clients depend upon the initial values; rather I want clients
to be able to depend on variables, types, whatever, _not_ being
_uninitialized._ There will always be something in there that's
"in-range" for the type. Clearly Ada83 thought this was worth doing for
access types, and look how much easier it is to write linked-list
packages because there are no garbage pointers to worry about (leave
aside the dangling-pointer problem left unsolved by Unchecked_Deallocation!)

I was told once by an Ada83 high priest that the reason record fields can
be initialized is that, syntactically, it's "free" because the syntax
of a field declaration is the same as the syntax of a variable declaration.
I got the impression that the thinking didn't go much deeper than that.
They didn't bother with initializers for other types because it wasn't free.

Mike

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>Perhaps I have completely misunderstood the point of default values for
>fields of records.  I thought that this, like default values for
>omitted parameters, was a dodge to help people cope with the problem
>where there is
>	-- a package P providing a record type or procedure, and
>	-- a package U using that record type or procedure
>and package P is updated to include extra fields in the record type
>or procedure, and it may not be practical to update the source of
>package U.  (In fact, U may be a customer who won't let you anywhere
>near their source.)  In this practically important but conceptually
>limited case, the package provider _can_ determine sensible default
>values: "those values which make the new version of the software
>act just like the old version".

Since I tend to use private types, this argument is spurious. If I
am providing a private type in P to which I have added a new field, U is
unable to initialize the fields ANYWAY: I must do it for the client,
since I am providing the abstraction upon which the client depends.

Furthermore, if each U was required to initialize the values in my
type, the odds of at least someone screwing it up increase linearly
with the number of U's.

Finally, consider this case:

    package Some_Package is

        type T is private;

        function Initialize (From_Some_Input : in A_Type) return T;

        procedure Do_Something (To_This_Object : in out T);

        Not_Initialized : exception;

    private
   
        type T is record
                      Some_Field : Some_Type;
                      Is_Initialized : Boolean := False;
                  end record;

    end Some_Package;

I, the provider of T, have a field in the record that is used to insure
consistency. The default initial value is not something the client can
override, so there is no way the client can pass an unitialized value
of T to me and get away with it. Without default initialization I cannot
ensure this.

    package body Some_Package is

        function Initialize (From_Some_Input : in A_Type) return T is
       
            The_T : T;

        begin
            The_T.Some_Field := Some_Normalization_On (From_Some_Input);
            The_T.Is_Initialized := True; <====***
            return The_T;
        end Initialize;

        procedure Do_Something (To_This_Object : in out T) is
        begin
            if not To_This_Object.Is_Initialized then
                raise Not_Initialized; <====****
            end if;
            {do whatever to the object>
        end Do_Something;

    end Some_Package;

This sort of thing is very useful for applications where data integrity
must be ensured (can you think of any where data integrity is NOT
important?...).

>Now consider the kinds of problems that can arise with default
>initialisations, *where the package user knows what the default is*.

That's not the issue: default initialization, particularly of private
types, is for the benefit of the SUPPLIER, not the client.

>One thing which would reduce this temptation would
>be to set things up so that a type or subtype can be specified in
>a package specification and its default value in the package body.

Actually, this is a pretty good idea, at least for visible types
(it doesn't matter for private types).
--
***** DISCLAIMER: The opinions expressed herein are my own, except in
      the realm of software engineering, in which case I've borrowed
      them from incredibly smart people.

Re: Pre-condition vs. Post-condition

[Michael Feldman]

In article <jls.670109695@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
  ... much good stuff deleted
>
>That's not the issue: default initialization, particularly of private
>types, is for the benefit of the SUPPLIER, not the client.

Right. As long as the client program(mer) doesn't make hidden assumptions
in the client code about what the default value is.
>
>>One thing which would reduce this temptation would
>>be to set things up so that a type or subtype can be specified in
>>a package specification and its default value in the package body.
>
>Actually, this is a pretty good idea, at least for visible types
>(it doesn't matter for private types).

True, but see my comment above. This is probably no worse a problem than
arises with Ada private types in general, where the private part is visible
to the human even if it's hidden from the human's code.


Mike Feldman

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>>That's not the issue: default initialization, particularly of private
>>types, is for the benefit of the SUPPLIER, not the client.

>Right. As long as the client program(mer) doesn't make hidden assumptions
>in the client code about what the default value is.

But a programmer who makes such assumptions is a doofus. I don't want
to remove features in the language that are useful for good programmers
just to make it harder for doofus programmers to act like doofuses: I
want fewer doofus programmers to have jobs. Just because it is possible
to write an erroneous program in Ada (and I submit that depending on
default values in private types is highly erroneous) is no reason to
damn the features that make such erroneousness possible. This is not
a language issue: it's an education issue.
--
***** DISCLAIMER: The opinions expressed herein are my own, except in
      the realm of software engineering, in which case I've borrowed
      them from incredibly smart people.

Re: Pre-condition vs. Post-condition

[Jim Showalter]

>I would rather see features that help people detect or avoid the error
>of using an uninitialised variable rather than features which define
>the problem away.

I think we disagree here. I don't view this:

    type Foo is Integer := 10;

    Bar : Foo;

as producing an uninitialized variable. I view it as initializing a variable
to a value deemed (for whatever reason) to be a good value.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."