[Boost.Test] [1.38] Handling unexpected exceptions and system errors
Hi, One of the things that sets boost apart from other frameworks is its ability to handle exceptions and report them. While I've used the BOOST_CHECK_THROW and BOOST_CHECK_EXCEPTION macros, I'd like a way to pass if an exception is thrown that we don't necessarily understand how to mention in the BOOST_CHECK_THROW or BOOST_CHECK_EXCEPTION macros. BOOST_CHECK_NO_THROW just makes sure no exception is thrown. In some ways it's an odd request to say "I expect some exception to be thrown that I do not care to specify", but that would work for us. In addition, it would be nice (and I bet it's already available) to be able to say "allow next test case to run in event of exception" or "allow next test suite to run In event of exception". Right now, all testing does seem to abort (none of the above macros are either present or coded in a way to match the system issue. Any tips on how to discover those values, or to go forward when some kind of exceptional condition is expected is appreciated. -Greg
Greg Christopher <gchristopher <at> vmware.com> writes:
Hi, One of the things that sets boost apart from other frameworks is its ability to handle exceptions and report them.
While I've used the BOOST_CHECK_THROW and BOOST_CHECK_EXCEPTION macros, I'd like a way to pass if an exception is thrown that we don't necessarily understand how to mention in the BOOST_CHECK_THROW or BOOST_CHECK_EXCEPTION macros. BOOST_CHECK_NO_THROW just makes sure no exception is thrown. In some ways it's an odd request to say "I expect some exception to be thrown that I do not care to specify", but that would work for us.
1. You can probably use std::exception. Chances are all your exception derive from it. 2. You can always write try catch(...) block yourself and check for you need there. 3. It's usually better to design system that throws something specific.
In addition, it would be nice (and I bet it's already available) to be able to say "allow next test case to run in event of exception" or "allow next test suite to run In event of exception". Right now, all testing does seem to abort (none of the above macros are either present or coded in a way to match the system issue.
Uncaught C++ exception is not fatal condition. The rest of the test units are expected to run fine. Please post an example if this is not the case. Gennadiy
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: Friday, June 26, 2009 12:57 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Boost.Test] [1.38] Handling unexpected exceptions and system errors
Greg Christopher <gchristopher <at> vmware.com> writes:
Hi, One of the things that sets boost apart from other frameworks is its ability to handle exceptions and report them.
While I've used the BOOST_CHECK_THROW and BOOST_CHECK_EXCEPTION macros, I'd like a way to pass if an exception is thrown that we don't necessarily understand how to mention in the BOOST_CHECK_THROW or BOOST_CHECK_EXCEPTION macros. BOOST_CHECK_NO_THROW just makes sure no exception is thrown. In some ways it's an odd request to say "I expect some exception to be thrown that I do not care to specify", but that would work for us.
1. You can probably use std::exception. Chances are all your exception derive from it.
2. You can always write try catch(...) block yourself and check for you need there.
3. It's usually better to design system that throws something specific.
In addition, it would be nice (and I bet it's already available) to be able to say "allow next test case to run in event of exception" or "allow next test suite to run In event of exception". Right now, all testing does seem to abort (none of the above macros are either present or coded in a way to match the system issue.
Uncaught C++ exception is not fatal condition. The rest of the test units are expected to run fine. Please post an example if this is not the case.
Gennadiy
Thanks. It looks like the same is not true for divide by zero and null pointer dereferences and other errors that are not caught by "catch" ? I like that the framework catches these somehow, but would be interesting to know if it's an option that the framework return control to the test program. None of the tools/macros seem to allow that. Greg
Greg Christopher <gchristopher <at> vmware.com> writes:
Thanks. It looks like the same is not true for divide by zero and
Integer divide by zero is treated as non-fatal system error (if it's actually produced by your hardware/compiler). It should not lead to the test being aborted.
null pointer dereferences and other errors that are not caught by "catch"?
All kinds of memory access violations are treated as fatal system error. This will abort the test execution (well it will try to do it gracefully, though some other things might fail in process)
I like that the framework catches these somehow, but would be interesting to know if it's an option that the framework return control to the test program. None of the tools/macros seem to allow that.
Return control where? Once any of the above are triggered, the test case is definitely aborted. whether or not test will continue depend on type of error. You can tell Boost.Test not to catch system errors/signals using command line argument "--catch=false" or "-s false" Gennadiy
participants (2)
-
Gennadiy Rozental -
Greg Christopher