Boost logo

Boost :

From: Daniel James (daniel_at_[hidden])
Date: 2005-12-20 13:54:01


Gennadiy Rozental wrote:
>>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(...)

Unordered associative containers have a few exception specifications
like (from TR1 6.3.1.1/2):

   "For unordered associative containers, if an exception is thrown by
any operation other than the container’s hash function from within an
insert() function inserting a single element, the insert() function has
no effect."

So the tests need be to sensitive to where the exception was thrown.
Currently I'm dealing this by throwing different types of exceptions
from different methods. Another, possibly better, way of doing it is to
be able to find out the location of the throw (maybe by using the scope).

It would also be possible to have multiple tests using different objects
to deal the different circumstances.

>>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)

This seems quite limiting to me, but in my case I can work around it by
defining a class level new as the false leaks aren't from the code being
tested, but the tests. I'm getting reports of memory leaks as they only
get cleaned up when the full test ends.

>>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.

I have a couple of classes that I use for testing for strong and basic
exception safety. In order to avoid writing try/catches everywhere they
do their tests in the destructor. So this is an exception safety test,
or at least an exception spefi

>>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
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk