Andrei Alexandrescu wrote:
I agree. I'm having the same problem: I put a contract in there, I know
it's as good as assert. So I can't do e.g. input validation because in
most functions input must always be validated. I also know that
contracts are doing the wrong thing with inheritance and can't apply to
interfaces, which is exactly the (only?) place they'd be interesting. So
I send the contracts home and use assert, enforce, and unittest.
Contracts are not for input validation! They are checking if the logic
of your program is correct or not. Think of it this way - your program
should behave exactly the same with or without the contracts turned on.
Contracts should NOT be used for scrubbing user input, checking for
errors from other components, or validating any input from external to
the dll.
If you feel the need to leave them on in a release build, then:
1) your testing is inadequate
2) you are using them incorrectly
For example, Windows API functions check all their input. This is not
contract programming - it's validating user input over which Microsoft
has no control.
