[Boost-users] [Boost.Test] [1.38] Handling unexpected exceptions and system errors
Greg Christopher
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
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Gennadiy Rozental
>
> 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
Greg Christopher
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
Gennadiy Rozental
> 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