Georg Wrede wrote:
Sean Kelly wrote:
== 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.
The distinction is not whether you or others write stuff. It's about
whether it is for debugging *only*, as opposed to general input validation.
So I guess the real question is whether a function is expected to
validate its parameters. I'd argue that it isn't, but then I'm from a
C/C++ background. For me, validation is a debugging tool, or at least
an optional feature for applications that want the added insurance.
Sean
