From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!seas.gwu.edu!mfeldman
From: mfeldman@seas.gwu.edu (Michael Feldman)
Newsgroups: comp.lang.ada
Subject: Re: Pre-condition vs. Post-condition
Message-ID: <2918@sparko.gwu.edu>
Date: 25 Mar 91 17:05:53 GMT
References: <20600091@inmet> <23141@as0c.sei.cmu.edu>
Reply-To: mfeldman@seas.gwu.edu ()
Organization: The George Washington University, Washington D.C.
List-Id: <comp.lang.ada>

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