Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-17 20:58:40

From: Jeff Garland <jeff_at_[hidden]>
> > > For fault resilient applications a typical strategy in libraries
> > > is to assert during unit testing and throw an exception
> > > in integration test and production. In production the exception
> > > is something like std::logic_error. Usually a macro handles
> > > the conditional compilation of the library.
> >
> > An application that must run 24x7 that's written in C or C++ pretty much must
> > have an automatic restart mechanism for robustness in any case. In server
> Yes, but restart is often the second layer of defense not the first.
> There are plenty of times when the whole application doesn't need to crash just
> because of a software error.
> > intervention. With the compilers I use, exceptions make it impossible to
> > generate a useful core dump that shows precisely what happened. I'd
> > rather have the core dump in the case of a logic error.
> I prefer to core dump too, but again not every application can
> take this approach. So, not making this an option will
> exclude the use of Boost.threads (and the Boost libraries
> which depend on boost threads) from those applications.
> Just as a point of reference, I don't think there are any
> C++ standard library implementations that take the assert
> approach.

In the Oracle server we avoid dumping core in production code, since
core files are so huge, but we do what takes on each platform to
generate a stack trace to a log file before aborting a transaction,
killing the server process, and starting up a new one. We also
treat anything that can so crash the server as a priority one bug.

In development code we contrive for assertions to generate a SEGV
and a core to allow for debugging after the fact. But performance
is critical so we turn off most assertions in production code.

Boost list run by bdawes at, gregod at, cpdaniel at, john at