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