On Tue, 03 Mar 2009 11:00:36 -0800, Walter Bright <[email protected]> wrote:
>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. This is exactly how I look at them. However I've never tried to use pre/post conditions. I guess it's because of the syntax. By the way, about that image on the contracts page. Is the bullet flying away from the D-man because it's disgusted by his extreme ugliness? :)
