On 20/06/2014 01:03, Ghyslain Leclerc wrote:
Then, I had the idea to check what the behaviour would be if the wrong exception is thrown. I simply changed the first call like this :
BOOST_CHECK_THROW( testRow.setCol( 30, 12 ), std::runtime_error ); BOOST_CHECK_THROW( testRow.setCol( 30, 12l ), std::out_of_range );
I was under the impression (and I might be wrong here, sorry :-( ) that the Boost.Test library would (the numbers are not to mean that order, simply there for enumeration): 1- output a message saying the test has failed, that an exception was indeed thrown, but it was not a runtime_error 2- continue the rest of the test (single test currently) 3- terminate
but I actually never get the message of step 1, the execution of the rest of the test seems never occur (the second BOOST_CHECK_THROW) and the program terminate because of my exception and not very gracefully.
I guess my questions to the other users here are: - Was my understanding of what BOOST_CHECK_THROW does flawed ? - Is the behaviour normal ? - Is there an obvious problem I am missing with the design of my simple class ?
If you look at the definition of BOOST_*_THROW in boost/test/test_tools.hpp, you can see that it only tries to catch the named exception; any other exceptions will be left to bubble up (and will likely be uncaught and result in terminate() getting called). So it sounds like it's behaving as expected from that viewpoint. (Having said that, there is some evidence of plumbing to catch all exception types at a higher level and do something more useful than calling terminate(); I haven't looked too closely at it so I don't know if it's involved in the behaviour you're seeing or not. Related docs at http://www.boost.org/doc/libs/1_55_0/libs/test/doc/html/execution-monitor.ht... suggest that this is optional and must be explicitly enabled to operate, though, but I could easily be missing something. But even if it's "working", it would still result in aborting at least the test case despite the CHECK level.) I agree with you that it would be more useful for this to be handled locally. You could try submitting that as a bug report in Trac (if it's not already there), or waiting for Gennadiy Rozental's response. In the meantime, you'd need to write a more intelligent test yourself. (I consider it a bug rather than a feature request because the reference docs for BOOST_*_THROW state that "check fails" if an unrelated exception is thrown, which is at least misleading at present if not incorrect.)