Good Contract programming idiom?

[Fawzi Mohamed]

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