I'm all for paranoid and pragmatic programming. (maybe not pedantic :-P ) I just wanted to point out that regardless of whether or not asserts are proper for some task or another, there are some common error conditions that should be returned in a few situations where you may think to use an assert. For example, a number of functions return B_BAD_VALUE if you pass a null pointer when you should have passed a pointer to an object. (usually so the function can return a value by using that pointer) Also, some functions return B_NO_INIT if a function is called before the object is properly initialized. Sometimes this is in the bebook information, but the bebook also often says "other errors may be returned", which could include these kinds of errors. I do believe that using an assert is better than not using anything. (generally asserts are easier to debug and may catch errors that manifest in obscure ways.) Returning an error condition has the side benefit that if the application can recover from the condition, it has the opportunity to do so. Given our current position of having a reference implementation (R5) you can and probably should run a few tests with bad values, to see what the current behavior is. If the current behavior is crash, then I think it's fair to say we can do better. :-) You may also consider writing up the bad value inputs as tests and checking them into cvs for the general benefit. Also, the behavior should also be documented, of course. :-) [says the programmer who hasn't figured out doxygen yet...] Andrew