Boost logo

Boost :

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

1. Macro does not support varargs. That mean We need add new macro into
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.


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at