"Sean Huang" <huangsean@hotmail.com> wrote in message news:BAY102-DAV13D47719BA8C237CA85EE7A3650@phx.gbl...

...

I am not sure I understand the context where you would need to log boost::test::execution_exception. Could you provide an example.

If the test creates a thread and the thread uses BOOST_CHECK. This probably wasn't a good idea to start with since as far as I know boost::test does not have a mechanism to catch the exceptions generated from other than main thread. A simple thread adaptor would be a nice addition to boost::test.

I will re-review threading issues in 1.35. For now I wouldn'r recommend this usage. The exception is part of internal implementation. It's not supported to be logged or caught by end users, so I do not see a need for an extra dependency/complexity. Gennadiy

"Stephan Tolksdorf" <andorxor@gmx.de> wrote in message news:44C66F85.5020505@gmx.de...

Gennadiy,

while we are discussing exceptions in Boost::Test, I've got a small request:

Could you maybe provide an equivalent macro to BOOST_CHECKPOINT (or extend BOOST_CHECKPOINT) whose message is also displayed if BOOST_REQUIRE fails? The reason I ask is that I sometimes outsource common testing routines into helper functions and would like to print context information if the test fails (as the line number itself is not very informative in these instances). I'm sure that would be a help to others too.

BOOST_CHECKPOINT would help you in this case. Lets consider your example: void testHelper(int param1, int param2) { std::ostringstream msg; msg << "Problem with param1: " << param1 << " Param2: " << param2 << "... \n"; BOOST_CHECKPOINT(msg.str()); // do some complicated operations (...) BOOST_REQUIRE_EQUAL(some_resulta, some_resultb); (...) // some more complicated operation BOOST_REQUIRE_EQUAL(some_resultc, some_resultd); } BOOST_AUTO_TEST_CASE(MyTest) { testHelper( 1, 3); testHelper( 7, 7); for (int i = 13; i < 51) { testHelper( 13, i); } } 1. Checkpoint in terms of Boost.Test is named passpoint. And passpoint is the position in a code test pass through. Primary purpose of passpoint is to report last position passed in case of fatal error or uncaught exception. Both BOOST_REQUIRE_EQUAL statements above will overwrite the checkpoint position. Even if BOOST_REQUIRE would report checkpoint position, it would not help you to separate 2 calls to testHelper. 2. The same issue actually applies to any Boost.Test tool: if tool is used in shared location there is no way to know the context: where the shared code was called from. Since in C++ there is no portable automatic traceback facility, we need some kind of explicit scope tracking. One solution is to use BOOST_TEST_MESSAGE based solution: struct boost_test_scope { boost_test_scope( const_string scope_name ) // report "Enter scope scope_name" ~boost_test_scope() // report "Leaving scope scope_name" }; #define BOOST_TEST_SCOPE( SC ) \ boost_test_scope scope_guard # __LINE__( (boost::wrap_stringstream().ref() << M).str() ) /**/ There 2 issues with this solution: 1. You need to setup log_level=message 2. Messages are reported always whether or not there were errors in this scope. An alternative would be new facility: test context. Boost.Test will keep track of registered contexts and will report the context with any failed assertion. We could also have a parameter that turn on/off context reporting. If this is acceptable solution I could implement this in 1.35. Gennadiy

An alternative would be new facility: test context. Boost.Test will keep track of registered contexts and will report the context with any failed assertion. We could also have a parameter that turn on/off context reporting.

If this is acceptable solution I could implement this in 1.35.

Something similar would be great... Thanks for your efforts, Gennadiy. Stephan