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.
