Invariant and pre/post-conditions order

[Steven Schveighoffer]

On Thu, 19 Jan 2012 20:38:05 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 1/19/2012 4:08 PM, Jonathan M Davis wrote:
>> On Thursday, January 19, 2012 17:29:28 bearophile wrote:
>>> If I am mistaken please I'd like to know why the current design is  
>>> better
>>> (or maybe why it's just equally good). Thank you :-)
>>
>> Honestly, I don't think that the order is all that critical, since all  
>> of the
>> same assertions are run in either case. But conceptually, the invariant  
>> is for
>> verifying the state of the object, whereas the post-condition is for  
>> verifying
>> the state of the return value. And the return value doesn't really  
>> matter if
>> the object itself just got fried by the function call. Not to mention,  
>> if your
>> tests of the return value in the post-condition rely on the state of the
>> object itself being correct, then your tests in the post-condition  
>> aren't
>> necessarily going to do what you expect if the invariant would have  
>> failed.
>>
>> I have no idea what Walter's reasoning is though.
>
> My reasoning is it (1) doesn't make any difference and (2) it's always  
> been like that - and if it did make a difference, it would break 10  
> years of existing code.

I have to disagree on some level with (1).  It might not make a difference  
in determining there is a bug, but it makes a difference because failing  
in the out-condition gives you more information, even if the invariant is  
broken.  It tells you which function broke the invariant.

Let's say you have a car diagnostic machine which has a choice of  
reporting one of two error codes, a) spark plugs aren't firing, and b) the  
car isn't starting when the key is turned.  Which one would you rather see?

-Steve