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.

Sort of, like it's not prudent to put an assert anywhere other than where the source code (that is, a bug or goof by the programmer) causes the assert to fire.

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

Reply via email to