Re: [boost] [test]exception safety testing

From: Daniel James (daniel_at_[hidden])
Date: 2005-12-22 16:17:36

Gennadiy Rozental wrote:

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

Would it be possible to supply a templated exception that could be used. 
Something like:

     struct hash_exception_tag {};
     typedef boost::itest::exception<hash_tag> hash_exception;

     // An exception derived from hash_exception
     struct hash_constructor_exception_tag {};
     typedef boost::itest::exception<hash_constructor_tag,
         hash_exception> hash_constructor_exception;

Would that be easier?

Although, I get the impression that making use of your scope tracking 
might be easier.

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

I was referring to something like:

   "For unordered associative containers, no swap function throws an 
exception unless that exception is thrown by the copy constructor or 
copy assignment operator of the container’s Hash or Pred object (if any)."

Which is from TR1 6.3.1.1/3. To be honest, this one is pretty easy to 
deal with, but I could imagine more difficult ones.

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

Sorry, I always concentrate on the negative.

It looks very powerful. It does a lot more than my test framework does 
and is better designed (my tests were thrown together as I went along). 
And it found a bug in one of my tests - I was using std::rand() but 
forgot to reset the seed at the beginning of each iteration, and your 
framework noticed that it was acting inconsistently. It will be 
interesting to see how this works in practice.

I think most of my problems came from trying to migrate my tests from my 
framework to yours. And the specification for unordered associative 
containers is fairly demanding, although with the increasing popularity 
of policy templates that could become more common.

I'll continue with it and let you know how I get on.

I forgot to answer this before:

> 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::itest::exception_safety could take an extra parameter which takes 
flags to turn of parts of the testing tracking (although that depends on 
how easy it is to seperate them). Maybe something like:

     boost::itest::exception_safety(&insert_test, "Insert Test",
         boost::itest::no_leak_detection);

I don't think there's any need to make this accessible through the macro.

Daniel