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

[Brian H. <bri...@py...>]

> 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" =)

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

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

> Note that invariants are called explicitly via a macro.  I used to 
> call these from the PRECONDITION macro, but that's annoying because 
> most classes don't have invariants and PRECONDITION and POSTCONDITION 
> are useful pretty much everywhere (if nothing else as a documentation 
> aid).

Right, which is a cornerstone of Eiffel's DbC.
 
Thanks for the code, it may take me a while to sift through all of it.

Brian