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

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-03-17 17:20:35

> 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 have sympathy with the idea of making resilient APIs which can stand up 
> 
>  >to
>  >nearly any kind of client abuse, but there is usually a significant cost 
> to
>  >this approach. If someone wants that sort of protection, it can usually 
> be
>  >provided as a layer on top of a simpler API.  I am utterly unsympathetic 
> to
>  >half-measures, though. An API which promises resilience against some, but
>  >not all abuse is an invitation to disaster.

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.

Jeff