Re: [boost] [test]exception safety testing

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-22 14:19:55

>>>For example, if an exception is thrown while rehashing a hash table, it
>>>will probably be left with only some of its elements - so the test needs
>>>to check that the size has been changed to match the decreased number of
>>>elements. Of course, that's possible within your framework.
>>
>> This is requirement for strong guarantee
>
> This is definitely the basic guarantee. From
> http://www.stlport.org/doc/exception_safety.html:
>
> "Containers continue to fulfill all of their requirements, even after an
> exception occurs during a mutating function. For example, a map will
> never give an inaccurate report of its size, or fail to meet its
> performance requirements because the tree that implements it has become
> unbalanced."

Ok. you right.

>>>Another version would be to have two separate tests, the first to test
>>>for basic safety:
>>>
>>>    unordered_set<test::mock_object,
>>>        test::hash, test::equal, test::allocator> x;
>>>    x.insert(1);
>>>
>>>and one to test for strong safety, with a non-throwing hash:
>>>
>>>    boost::unordered_set<test::mock_object,
>>>        test::hash_nothrow, test::equal, test::allocator> x;
>>>    unordered_strong_test tester(x);
>>>    try {
>>>        x.insert(1);
>>>    } catch(...) {
>>>        tester.test();
>>>        throw;
>>>    }
>>
>>
>> This is a correct way of structuring your tests. Don't mix basic and 
>> strong
>> test withing the same test case. TDD actually recommends to have separate
>> test case for every single assertion. And in this design you do not need 
>> to
>> know where exception was thrown from.  It's possible that your class 
>> needs
>> to check different invariants depending on where the failure occur. Do 
>> NOT
>> do this within same test case. Use two - with different mocks throwing
>> exceptions in different locations and different invariants checks.
>
> That seems very dogmatic. Personally, I find the other styles more
> expressive. And while you might not need to know where the exception is
> thrown from, you need to control where it can be thrown from, which
> seems like more of an effort to me.

I guess it could be a matter of preference. I could try to support 
alternative that throw user supplied exception. There are several 
complications:

1. Macro does not support varargs. That mean We need add new macro into 
interface
2. Currently all methods are virtual. I couldn't pass custom user exception 
throw non-template virtual call.

> Some of the other exception
> specifications details which methods exceptions can be thrown from, so
> you need quite fine-grained control.

Sorry I did not get this statement.

Gennadiy

P.S. Other then issues we discussing now, what is you general impression of 
new facilities?