Good Contract programming idiom?

[Norbert Nemec]

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.)