Re: [Boost-users] [Boost.Test] [1.38] Handling unexpected exceptions and system errors

Subject: Re: [Boost-users] [Boost.Test] [1.38] Handling unexpected exceptions and system errors
From: Greg Christopher (gchristopher_at_[hidden])
Date: 2009-07-01 14:23:12

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Gennadiy Rozental
> Sent: Friday, June 26, 2009 12:57 PM
> To: boost-users_at_[hidden]
> 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