RE: [GD-General] Assertions, pre/post-conditions and call tracing

[Jesse J. <jes...@mi...>]

At 2:25 PM -0800 1/15/02, Brian Hook wrote:
>  > Are you sure this is true? It doesn't make sense to me: if a method
>>  is unable to complete and has to throw an exception the
>>  post-condition need not hold (eg an AddObject() method may not
>>  actually add the object if it runs out of memory).
>
>Sorry, I meant "no matter how it is exited, barring exceptions" =)

Ahh, that would be nice. Another tough thing to do in C++ though.

>  > Invariants aren't too bad. The hard things revolve around pre and
>>  post-conditions. The hardest is that derived classes are allowed to
>>  weaken pre-conditions and strengthen post-conditions (ie they may
>>  accept a wider range of input and more tightly specify what they
>>  return).
>
>Under Eiffel this isn't the case (at least, I don't think it is) -- you
>can only strength both pre and post-conditions.

Nope, just looked it up. Derived classes *can* strengthen 
post-conditions. What this means is that the derived class promises 
to do a bit more than the base class. In other words after the method 
call the possible derived object states are a subset of the base 
object states. But this is still OK because client code has to work 
with the original post-condition.

>  > The other problem is that objects can temporarily fall into a bad
>>  state as their methods execute. This can cause problems if a public
>>  method winds up being called. The fix is to only call the invariant
>>  method when a public method is first entered and exited. This does
>>  turn out to be a problem in my experience.
>
>Yes, that's true, but my guess is that this is more of a case of
>defining the proper invariants, otherwise you would be in hell with
>either a lot of in-line code, or a bunch of helper functions that were
>reporting erroneous conditions.

I'm not quite sure what you're saying here. The problem I'm talking 
about has nothing to do with "proper invariants". In fact, the 
stricter the invariant the more of a problem you have. You can 
eliminate the problem by adopting a convention of having public 
methods call private helper methods instead of the public methods, 
but this is a lot to ask of clients.

   -- Jesse