Re: Building blocks (Was: Design By Contract)

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

Robert A Duff wrote:
> The exception handler would still be required to obey
> the postcondition.

With the exception that postconditions (even if you writen them down as
raise_statements) aren't handled as well as in Eiffel: They aren't
automatically included in the package documentation, and they aren't
automatically inherited by descendants (if it's a tagged type).

> Either way, there's always the danger that the
> programmer forgot to handle some case correctly.

Agreed.

> Furthermore, retry seems to have all the bad properties of goto.  And
> the worst sort of goto -- the kind that jumps backwards in the code,
> forming a loop, without actually writing "loop" at the front.

I don't particularly like the semantics of retry. I've already seen
Eiffel code that was so obfuscated by squeezing the error handling logic
into a loop that it was actually wrong. And the author was actually one
of the Big Names in the Eiffel community...

Personally, I'd prefer the C++/Java style:
  try
    -- code that may raise an exception
  on <exception identification> do
    -- exception handler
  on <other exception id> do
  ...
  end
(ad-hoc syntax).

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.
The Eiffel solution is marginally better - it says "if it don't work,
don't try to fix it, try again if there is anything to do about it".
This policy isn't wrong, but it doesn't cover all cases where an
exception might be raised.

[good examples of obfuscated retry statements snipped]

> >"This mechanism strictly adheres to the Disciplined Exception
> Handling
> >principle: either a routine succeeds, that is to say its body
> executes
> >to the end and satisfies the postcondition, or it fails.
> 
> This is a bogus definition of "succeed".  The only sensible definition
> is "obeys the postcondition".  And that could be achieved just as well
> without retry.

Yup.
Though Ada has no formal connection to postconditions, so it doesn't
offer us guidelines what to do about an exception.

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)
- 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).
- A strong guideline *not* to use exceptions as interprocedural goto.
(I'm pretty sure that this is frowned upon by all serious Ada shops, but
it's still a difference if such a guideline is expressed in all
textbooks from the beginning of if you have to install such a policy. I
call such conventions "language culture" - it's not part of the formal
specification, but important enough to strongly influence the average
quality of programs written in a language.)

> In summary, I think it's postconditions that help make routines work
> properly in all cases (including exceptional cases).  I don't see any
> way in which "retry" helps ensure that postconditions are obeyed, and
> I
> think retry simply makes the code more confusing.

Right.

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