Re: Pre-condition vs. Post-condition

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 (actually inintialization)

[Dana Carson]

In article <2937@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
>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
>Mike

  Actually IMHO it should be possible to initialize variables with INVALID
so that it isn't anything legal so that you know that it hasn't been
set.  I believe that Rational allows this on it's machines?

  I do this with enumerated types quite often but you can't do ti with
integers, and I have to put in the checks for the enumerated types
rather than an automatic exception like with ranges. 

--
Dana Carson
Westinghouse Electronic Systems Group  Mail Stop 1615
UUCP:carson@tron.UUCP 
     carson@tron.bwi.wec.com
     ...!uunet!tron!carson
AT&T: (301) 765-3513
WIN: 285-3513

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

Initialization

[Paul Stachour]

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

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

As one who has programmed regularly in more than an half-dozen languages,
and has worked on teams that have implemented 3 compilers for different
lanauges, I agree.

If you have a variable that is unitialized, then a good flow anyalysis
tool (we had some inside one of the compilers) can follow your
control-flow and give you "used before set" messages.  When you do
have something initialized, it is, by definition, set.  Thus the
flow-analysis gives you nothing.

I long for the (ancient) FORTRAN II compiler I used on an IBM 7074
in the mid-1960s.  It set all of the words in the machine to an
"invalid pattern" before beginning your program.  And then if you
fetched anything that hadn't been set, you took a hardware fault and
the run-time told what you were doing wrong.

Much like Saber-C and other good c-interpreters can do today,
but with hardware support.

One problem is when you have an uninitialized item as a component
of a struacture and you assign one instance of the structre to another.
Do you get a fault or not.  You really aren't "using" the item yet.

Enjoy. ...Paul
-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112
                             [1]-(612) 482-7467