[Boost.Test] Detail lost when using BOOST_*_NO_THROW
Hi again, While developing tests I sometimes find that functions that should not throw exceptions do. Because this is an unexpected situation, I would like to know what exception has been thrown so I know what problem to look for in my test design. Unfortunately the Boost.Test framework only provides a terse message like this: test.cpp(123): fatal error in "fnTest": exception thrown by test(); It doesn't tell you which exception was thrown, nor the reason why. Is there some way to tell Boost.Test to include the exception message (from what()) if the exception derives from std::exception? This would make problem solving much quicker as you would not have to run the tests through a debugger to see which exception is being thrown and why. There is some discussion about this on Stack Overflow[1] but the consensus seems to be the best solution is not to use BOOST_*_NO_THROW. If you don't use these and an exception is thrown, a lot more detail is provided. Assuming this is a limitation in Boost.Test, would it be possible to add this as a feature so that future versions include the same level of detail whether you use BOOST_*_NO_THROW or not? Many thanks, Adam. [1] http://stackoverflow.com/questions/15133259/boost-check-no-throw-how-to-get-...
[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <20131222101745.6cff920b@rid> thusly:
Unfortunately the Boost.Test framework only provides a terse message like this:
test.cpp(123): fatal error in "fnTest": exception thrown by test();
It doesn't tell you which exception was thrown, nor the reason why.
The only place I can find this text is in the implementation of BOOST_{WARN,CHECK,REQUIRE}_NO_THROW(). Are you really writing a test about exception handling, or is this a side-effect of your test case? IMO, unless you are exercising the exception handling properties of a piece of code, you shouldn't be using BOOST_xxx_NO_THROW -- any test case will fail if the exercised code throws an exception. So if you are testing normal functionality of the code, then just let the unexpected exception be thrown and the test framework should print an appropriate message. For instance, this code: #include <stdexcept> void foo() { throw std::runtime_error("What the hell?"); } BOOST_AUTO_TEST_CASE(test_foo) { foo(); BOOST_REQUIRE(true); } fails with this output: Running 1 test case... unknown location(0): fatal error in "test_foo": std::runtime_error: What the hell? -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com
Adam Nielsen
Hi again,
While developing tests I sometimes find that functions that should not throw exceptions do. Because this is an unexpected situation, I would like to know what exception has been thrown so I know what problem to look for in my test design.
Unfortunately the Boost.Test framework only provides a terse message like this:
test.cpp(123): fatal error in "fnTest": exception thrown by test();
This is an output of BOOST_REQUIRE_NO_THROW, right? There is very little reason to use this tool. Just leaving the expression along would do the trick (just as the discussion in the link below suggests and Richard in another reply). I probably should just remove this tool to avoid confusion.
There is some discussion about this on Stack Overflow[1] but the consensus seems to be the best solution is not to use BOOST_*_NO_THROW. If you don't use these and an exception is thrown, a lot more detail is provided.
Yep.
Assuming this is a limitation in Boost.Test, would it be possible to add this as a feature so that future versions include the same level of detail whether you use BOOST_*_NO_THROW or not?
I do not believe this is a limitation. BOOST_CHECK/WARN_NO_THROW is another story. Problem here is I do not want to replicate the whole machinery of identifying exception for every single assertion. I think the best policy in this case would be to just follow TDD recommendation and place single check per test case. No need for assertion at all, just invoke you code and Boost.Test validates that it runs fine or reports proper error otherwise Regards, Gennadiy
participants (3)
-
Adam Nielsen -
Gennadiy Rozental -
legalize+jeeves＠mail.xmission.com