Stephen torri wrote: > So while asserts enable us to find out errors in the crypto++ library I > agree that they should be remove before a release once the library has > been tested thoroughly.
Not just errors in the CryptoPP library, but also errors in the input data to methods of a class in the library. I don' t know about anyone else, but all the asserts I've had to troubleshoot were because the data I sent to a CryptoPP function was incorrect - usually a NULL pointer. It's been pointed out in earlier messages that asserts are not compiled into release code, but only into debug code. Personally, I like the way an assert throws me into the debugger with a call stack, etc, to help me determine what caused the assert. That's much better than having someone that's using my program call and complain about an unexplained shutdown - when I finally figure out that it's being caused by an unhandled exception. > The return types of functions need to be > reconsidered or honored if the function does nothing but throw an > exception. Function declarations should report that they throw the > exception so that an application written to them can catch these > run-time exceptions. I'd like to have an alphabetical list of classes, with each method listed and the asserts or exceptions each method can throw. Such a list would be especially valuable in abstract classes if it listed the derived classes and the exceptions thrown in each (by method). I don't want it badly enough to make it up myself, so therefore it isn't very important... Rickey
