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