comment about "design by contract , by example"

I really enjoy it when a book has something in it that makes me go wow.

This book has one of those. It's not a major wow, but still.

It talks about how defensive programming can lead to difficult to find bugs. I'm a big fan of defensive programming, so it got me thinking.

Basically, the point was that for non Design by Contract (DbC) languages, the problem is that if a function just returns if the parameters are not valid (i.e using guard clauses), then the bug/issue may not be discovered and if it is, it may be in an unrelated place - Fair Point.

The DbC language will throw an exception if the contract is invalidated - Nice.

Although, and there's always an although, I'm a big fan of a concept that I call Pipelining. That's where the function will only act when the parameters that are passed require it to act. This means that the conditions of execution are placed in the function, not dispersed throughout the code.

These two concepts kind of disagree with each other!

Hmmm...

I guess this is why development is hard?