On exceptions, errors, and contract violations

[bearophile via Digitalmars-d]

Sean Kelly:

> Another issue is what the error tells us about the locality of 
> the failure.  A precondition indicates that the failure simply 
> occurred sometime before the precondition was called, while a 
> postcondition indicates that the failure occurred within the 
> processing of the function.

In presence of high-order functions the assignment of contract 
failure blame is less simple.


> Invariant failures might indicate either, which leads me to 
> think that they are too coarse-grained to be of much use.  In 
> general, I would rather know whether the data integrity problem 
> was preexisting or whether it occurred as the result of my 
> function.  Simply knowing that it exists at all is better than 
> nothing, but since we already have the facility for a more 
> detailed diagnosis, why use invariants?

Invariants are more DRY. There are plenty of state parts that can 
be changed by a function, if you want to test the invariant each 
time you risk duplicating that testing code in every 
post-condition. The invariant helps you avoid that. It's a safety 
net that helps against problems that you can forget.

Bye,
bearophile