== Quote from Walter Bright ([email protected])'s article > 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.
Why should contracts be limited to parameter checking of internally used functions only? If I write a function and document parameter constraints then I certainly expect those constraints to be followed regardless of whether I'm calling the function or someone else is calling the function. Checking these via a contract simply provides an optional means of ensuring that a logic error didn't occur within the program as a whole. If you're talking about application input however, then I agree completely. ie. stuff typed in by the user, read from a file, etc, should never be validated within a contract because an input failure at that level doesn't represent a program logic error but rather user error. An assertion failure isn't a terribly good way of notifying the user that they shouldn't have put an alphabetic character in a box intended to receive an integer :-) Sean
