Re: Building blocks (Was: Design By Contract)

[Joachim Durchholz <joachim.durchholz@munich.netsurf.de>]

Matthew Heaney wrote:
> 
> In article <3423BE13.9C3852A4@munich.netsurf.de>, Joachim Durchholz
> <joachim.durchholz@munich.netsurf.de> wrote:
> 
> I don't understand what you mean by "resume execution at the point
> where
> the execution [exception?] occurred," because Ada does NOT resume
                 ^ yes that's what I meant
> execution
> at the point of the exception.  Rather, normal execution is abandoned,
> and
> control passes to the exception handler.

Sorry, I take that point back. There was a mental mix-up involved.

> You are correct in stating that the exception handler can't know at
> which
> point the exception occured, but only if there is a "large" amount of
> program text covered by a handler, and there is more the one place
> where
> the exception can occur.  The solution in this case is to localize
> handling
> of the exception, so that it isn't ambiguous:

Agreed.

> >Though Ada has no formal connection to postconditions, so it doesn't
> >offer us guidelines what to do about an exception.
> 
> While it's true that Ada syntax does not include a mechanism of
> specifying
> which exceptions can be raised by a subprogram, I wouldn't say that
> there
> are "no guidelines" for what to do about an exception.  You simply
> state -
> in the form of a comment - which exceptions can be raised by a
> subprogram,
> and handle them as appropriate.

Hmm... that's exactly what I mean. I'm sure your shop has conventions on
what form these comments should take, but other shops might have
different forms. So you have to train every new programmer to write the
"right" comments. So you can't sell a database that collects the
exception information. There are *many* advantages to have a fixed
syntactical place to place the postconditions.

> >What's disciplined about Eiffel exceptions is not the retry
> instruction,
> >which is somewhat secondary. The discipline of exception handling in
> >Eiffel has other sources:
> >- A precise definition of what an exception indicates (namely a
> routine
> >that fails to fulfill its postcondition - other languages, lacking
> the
> >notion of postcondition, can't even start to compete)
> 
> This statement confuses syntax with semantics.

Huh?
A postcondition has a very real semantics in Eiffel. The syntax is just
that - syntax that's necessary to indicate the compiler what these
boolean expressions are about.

[Stuff on not formalizing the set of possible exceptions for Ada
snipped.]

> It is clearly
> not the
> case that Ada - or any other language - "lacks a notion of
> postcondition."

Oh yes it does. In the same way as assembler lacks the notion of
parameter type - yes you can emulate it by heavy commenting and adhering
to informal guidelines, but then the notion is not implemented in the
language, it is implemented in the programming organization around that
language.

> Of course, there's nothing to prevent a programmer from failing to
> fulfill
> his postcondition, or from raising exceptions he hasn't advertised,
> just as
> there is no way to prevent a programmer from returning the value of
> the
> cosine from a function called Sin.  But this is a programmer problem,
> not
> an Ada problem.

Yup. And nothing will prevent an Eiffel programmer from doing the same.

However, such errors are more obtrusive in an Eiffel class. Eiffel
routines are typically very short, so a mismatch between a routine body
and its postcondition is often obvious at the first casual glance. (Of
course most programmers will see that even before writing the bug, so
not many bugs of this type manifest themselves to begin with.)

> >- A strict guideline when to raise an exception explicitly: if
> something
> >uncontrollable happens that makes fulfilling a postcondition
> >imnpossible. Such uncontrollable events are: actions by concurrent
> >threads, bugs, unhandled exceptions in called routines, and
> algorithms
> >where controlling the problems is nearly as expensive as just trying
> >(like in matrix inversion, where determining wether a matrix is
> >invertible takes nearly as long as just starting the inversion and
> >aborting if a division by zero occurs).
> 
> This is the same guideline one uses in Ada.

It's the guideline that *should* be used in Ada. But I'd bet it isn't
always followed - with pressing deadlines and less-than-perfect
programmers in the shop, you can't be sure that your company's
guidelines will always be followed to the letter or (more importantly)
in spirit.
In Eiffel, letter and spirit are the same, and the policy is already
enforced by the compiler.

Regards,
Joachim
-- 
Please don't send unsolicited ads.