exception safety validation

[François Dumont]

Some feedback ?

Can I simply commit the proposed patch ?

Thanks

François


On 09/28/2012 10:14 PM, François Dumont wrote:
> Hi
>
>     I enhance scope of the small exception safety test framework used 
> to validate different levels of exception safety through the 
> containers operations. I have added calls to C++ methods 
> emplace/emplace_front/emplace_back/emplace_hint in C++11.
>
>     Doing so I start having propagation_consistency test for vector to 
> fail. I finally realized that the problem was that the 
> throw_value_limit used for this test had no move semantic. So the copy 
> constructor and assignment operator was called sometimes throwing 
> exceptions. In this case the Standard says that there is no strong 
> exception safety guaranty explaining why the test was failing.
>
>     To fix it I have added for the moment move semantic to the 
> throw_value_base type so that it never throws. I had to remove the 
> dg-do run { xfail } in the equivalent deque test that was surely 
> failing for the same reason.
>
>     Now I wonder if there is something in the Standard saying that 
> move construct/assign shall never throw ? At least, on vector 
> modifiers it is clearly said that if the move constructor throw it can 
> have undefined behavior. If move construct/assign can throw then we 
> might consider a way to control wether or not it will throw depending 
> on the test. When testing vector and deque it shall not throw, when 
> testing node based container it can throw. What do you think ?
>
>     I also wonder what are all the try { ... } catch (const 
> __gnu_cxx::forced_error&) { throw; } in safety.h for ? Is it to 
> influence the exception callstack ?
>
>
> François
>