Re: [boost] [test]exception safety testing

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-20 14:35:35

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

Why? I do not follow you. Test needs to check that if any function call 
other then hash function invocation throw *any* exception specific invariant 
(in this case: size() is the same) is satisfied.

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

I am sorry this is completely unclear to me. Maybe some code example?

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

And here?

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

I realize that global operator new overload bound to cause some false 
positives under some circumstances. Users will need to address this in their 
code. If you have any better proposition I am all for it.

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

To check basic ES you don't need to catch any exceptions. Framework will 
check that you do unwinding properly by making sure you are not leaking any 
resources. To check for invariants (strong ES) my recommendation is to use 
catch(...) and do this on test function level preferably. Every ES test 
consist of series of tests for all possible execution paths.  Failed 
invariant abort the execution path testing and skip to next.

> So this is an exception safety test,
>or at least an exception specification test

This is two completely different things. This facility only bothers with 
exception safety.