Good Contract programming idiom?

[Lionello Lunesu]

You make a good point, but there's one problem I have with this.

I'm looking at this as a library writer. I can write in-contracts with
assertions, but I would not feel comfortable with only assertions, since
I know they will not get compiled in a release build of the library.

So in a release build I don't want anything weird to happen when wrong
arguments are passed to my library function. This can only be prevented
by throwing run-time exceptions, right?

L.

On 4-3-2010 3:04, Norbert Nemec wrote:
> Lionello Lunesu wrote:
>> On 2-3-2010 20:44, bearophile wrote:
>>> What do you think? Do you agree that's better to use exceptions like
>>> this to test arguments in public methods (instead of using asserts in
>>> preconditions)?
>>
>> I agree with you. I also prefer exceptions for illegal argument values.
>> I test them with asserts only in private methods.
> 
> No! No! No! Design-by-contract means that it is the application's duty
> to make sure that argument values are correct. If the program is
> correct, the library can trust that the argument values are correct and
> does not need to do checks. This is exactly the same situation that
> assertions are for: Double-checking something to catch potential bugs.
> 
> Exceptions are a very different issue and should never be used for this
> purpose.
> 
> A library interface simply is something different than a user interface.