Re: Building blocks (Was: Design By Contract)

[mheaney@ni.net (Matthew Heaney)]

In article <3423BE13.9C3852A4@munich.netsurf.de>, Joachim Durchholz
<joachim.durchholz@munich.netsurf.de> wrote:


>I don't like the Ada solution either. It is "structured" in that it will
>resume execution at the point where the execution occurred, but that's
>*very* wrong. The exception handler can't know at which point in the
>code the exception occurred (maybe even in a subroutine!), so it can't
>know what to do to fix the problem.

I don't understand what you mean by "resume execution at the point where
the execution [exception?] occurred," because Ada does NOT resume execution
at the point of the exception.  Rather, normal execution is abandoned, and
control passes to the exception handler.

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:

begin
   X := new T;
exception
   when Storage_Error =>
       raise Stack_Full;
end;


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

>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.  By a very deliberate choice
during language design, 
there is not always a way in Ada to state syntactically what the
postcondition of a subprogram is (and never any way to state what
exceptions are propagated by a subprogram).   However, in Ada, you do state
what the postcondition is, in the form of a comment.  It is clearly not the
case that Ada - or any other language - "lacks a notion of postcondition." 

So yes, in Ada, you really do raise an exception when you are unable to
satisfy a postcondition, it's just that the postcondition and possible
exceptions raised cannot be stated as part of Ada syntax; they must be
stated as a comment.

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.

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

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271