Especially in the Test-Driven Development literature, there is a lot of advice about avoiding writing too much into the code (You are not gonna need it: YAGNI). Well, that might be true and it might not be.
The flip side of YAGNI is defensive code. It boils down to a question of risks. What are the pros and cons of that extra code? As a concrete example, consider a method that uses an attribute that happens to be a pointer. Defensive coding practice says "always check pointers before dereferencing them." But there is a class invariant that ensures the pointer is always good. Do we check the pointer each time (wasting CPU cycles), or trust that nothing has gone wrong with the class invariant? The cons of using a bad pointer are, well, pretty bad (read "high risk"). Okay, so now we decide to check the pointer. This means there is a point in the code where we have a potential software error. Now we have to deal with that error.
As software engineers we are constantly encountering these sorts of tradeoffs. The answer we choose will depend on the project. This is where we should be guided by our software architecture and the story it is telling us.