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?