Basically, the N actions will be able to be customized (that is, you'll be able to add your own levels). What you say, about throwing an exception, also will be possible, since you'll be able to set a "handler" for each level of assertion. So, for instance, for assertions with level Debug (default), you can set a handler that will throw. Just like that! At run-time! (you can leave the default handler for assertions, that will prompt the user, etc. , or just set your own, which can throw an exception).
This sounds good. So if I want to do a test that a function does actually assert with bad data I can switch to exceptions, do a BOOST_CHECK_THROW() test, then switch back to normal assertion behaviour.
Following on from that, there seems some overlap between your proposed asserts and Boost.Test's BOOST_CHECK_() macros. I wonder if it would be possible to have an assert handler for use in the unit test framework, and then I can use SMART_ASSERT() in both main code and in test code and only have to learn one syntax.
others have picked up and continued developing it. Some of the initial constraints have been loosened, therefore, some of the ASSERTs became unnecessary.
Had such an ASSERT throw, some handler might catch it, and this could go undetected. What do you think?
Yes, that is another problem with asserts throwing exceptions that I'd not considered.
Darren
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost