Re: [boost] Re: Boost.Threads draft library submission

From: John Panzer (jpanzer_at_[hidden])
Date: 2001-03-17 18:32:43

Jeff Garland wrote:

> > At 02:43 PM 3/17/2001, David Abrahams wrote:
> >
> >  >IMO using the question "is this an exceptional situation?" to decide
> >  >whether
> >  >to throw an exception has an attractive ring to it, but is usually a
> >  >mistake. A more appropriate question to ask is: "do we want stack
> > unwinding
> >  >here?"
> >  >
> >  >As a developer, if I have violated a precondition of a library I'm using,
> > I
> >  >don't want stack unwinding. What I want is a core dump or the equivalent
> > -
> >  >a
> >  >way to inspect the state of the program at the point where the problem
> > was
> >  >detected. That usually means assert() or some equivalent.
> >  >
> >  >...
> I guess I don't understand how anyone can create applications which
> must run 24X7 and survive programmer errors with any library that
> takes the "assert policy".  It's one thing if they can be compiled
> out, but I don't think that's what's being suggested....
>
> 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
software, this is typically done with a monitor process of some kind that not
only restarts the process but generates alerts in situations that require human
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.

John Panzer