Fawzi Mohamed wrote:
On 2-mar-10, at 15:50, Norbert Nemec wrote:
bearophile wrote:
But generally public functions must test arguments in release mode
too, so I (and lot of other people) don't like to use asserts in this
situation. It's better to use an always present test followed by a
throw (so such test is not in the precondition).
For this statement, you should make a distinction between libraries
and applications.
Indeed, contracts are part of the interface, so a released library
should still allow to check for them.
Breach of a contract, however, is always a bug. In a correct program,
user interaction should never break either contracts or assertions. If
you trust your code enough to drop the assertions, you can just as
well drop the contracts.
The correct way to handled contracts for libraries would actually be
to store them as part of the library interface information. A
release-mode library would then contain neither assertions nor
contracts, but leave it to the compiler to add contract-checks for
calls to the library, when compiling an application in devel-mode.
well there are checks that I want to keep also in deployment, for
example if they check stuff that depends on user input.
Yes and if (!x) throw ...; is the correct way to handle this, but
sometime for stupid checks I would like to use the compactness of
assert, I already thought that having a aassert (always assert) would be
nice...
That strategy is fine for quick-and-dirty code, but for any code that
you actually want to allow others to use, it is not a good idea. Since
the terms "quick-and-dirty" and "deployment" are mutually exclusive,
there should not be a problem here...
If you want simple checks for user input, just define a routine
yourself, but don't call it 'assert'. If you want to be really helpful
to the user, let this routine write
"You did something wrong!"
to avoid being blamed for a bug.
(Whenever I encounter a assertion failure in a program that I use, I
silently assume that it is a bug.)
