Re: [boost] [test]exception safety testing

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-18 18:00:57

> It would be good to able to use my own exception types instead of
> Boost.Test's private exception type. You could possibly write a version
> of BOOST_ITEST_EPOINT which lets the user specify their own exception
> type, and some kind of mechanism to specify which exceptions are allowed
> seems essential.

Why would you need an ability to specify which fake exception to throw? This 
facility tests namely this ability of your code to do unwinding properly in 
case of any exception in any place.
You don't really need to know which exception it was. To check post 
exception invariants you could use catch(...)

> It would also be very useful to be able to tell where an exception was
> thrown from. Since you're already tracking scopes, maybe there could be
> a way of telling if it was in a specific scope?

If an execution path causing a memory leaks and failed invariant log shows 
an execution path traceback (try est_example2). An exception is marked by 
"Failure point". Also you could specify
--break_exec_path parameter and execution will about in failure point.

> My tests store some data in globals (in anonymous namespaces), and these
> are causing the memory leak detector to complain. So can I turn it off?

1. Keep in mind that in general exception safety test meant for small local 
checks and not intended for huge code pieces. Accordingly all global data 
should be initialized outside of test scope (usually, unless you are doing 
the global init testing)

> I'm using a custom allocator which detect leaks anyway, so I don't need 
> it.
If you are using custom allocator you shouldn't be affected by operator new 
overloads. In some cases you could implement class level new to prevent 
overloaded new invocation.

As a last resort there is a macro BOOST_ITEST_NO_NEW_OVERLOADS that needs to 
be defined both for library and test compilation. But then nothing is going 
to be caught by my facilities.

> BOOST_CHECK now seems to throw an exception, but I've been using it in
> destructors. So is this really needed? If it is, can you make the
> exception type public so I can treat it differently to other exception
> types.

This test is not intended to perform anything else but exception safety 
test. So DONT use Test Tools inside your test code unless you are testing 
for invariants. Any Test Tools failure is treated as failed invariant and 
execution path is aborted. No need to catch this exception - error found 
already.

> Also, exception_safety.hpp should include <boost/bind.hpp>.

I did not included it intentionally, since to use macroless interface you do 
not need one and I did not want to incur unnecessary dependencies.

Gennadiy