"Thorsten Ottosen" <[EMAIL PROTECTED]> wrote in message 02df01c28e4f$15cc5b30$76c3a8c0@nesottolap">news:02df01c28e4f$15cc5b30$76c3a8c0@nesottolap... > ----- Original Message ----- > From: "Peter Dimov" <[EMAIL PROTECTED]> > [nip] > > In general, it is recommended practice to always assert() preconditions in > > client code, instead of relying on in-library asserts. First, the library > is > > not required to have asserts, and second, the earlier you catch > precondition > > violations, the better (call stacks aren't universally available). > > I don't get this. It's a poor library if it does not even check its own > preconditions > in eg. debug mode. Moreover, if you put the precondition in the library, you > take the burden away from the client; this is highly recommeded since it > encapsulates > commen code _one_ place, not O(n) places! >
On the other hand, if the library writer does check the precondition and it fails, there isn't too much he can do other that immediately abort the program or throw a very general exception. Whereas if the end user checks the precondition he may be able to write code that corrects the error, or at least throw a specific exception that lets the user know exactly where and when the mistake occurred. If both the end user and the library writer check for the same error condition the library writer's check is a waste of time. This reasoning is why the STL vector class includes both operator[]() and at() member functions. Joe Gottman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
