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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-17 22:22:09

From: David Abrahams <abrahams_at_[hidden]>
> From: "Jeff Garland" <jeff_at_[hidden]>
> > > STLport in debug mode. I think you can configure it to throw exceptions,
> > > too, but I'm not sure. Assertions are the default.
> > >
> > > -Dave
> >
> > Right, it is user configurable, which I guess is what you were suggesting
> > for boost.threads?
>
> Not neccessarily. Sometimes assertions are used to check the sanity of an
> implementation. I don't want those throwing exceptions like "INTERNAL ERROR
> THAT'S NOT YOUR FAULT" at well-behaved clients (I love when compilers do
> this).

Yeah, but I hate it when compilers just crash with no clue as to why.

Still, I agree that exceptions are generally not the way to handle
precondition violations or other unrecoverable problems.

> Moreover, I am not at all convinced it is appropriate for our libraries to
> attempt to check for client abuse. If and where we /do/ decide it is
> appropriate, I agree with the idea of using configurable response
> strategies. I also believe it is usually best to put these checks in a
> separate layer on top of the base implementation, rather than trying to
> weave them into the release code.

In general, it depends.  For Oracle the rule is that no client should
be able to crash our server, and that no server crash should be able
to damage client data.  But for STL that rule would be a disaster for performance.  It's a difficult tradeoff, and I appreciate that
William
is working hard to make the right choices.

> -Dave
>
> P.S. Configurable assertions in STLport was added at my suggestion. I was
> targeting MacOS where assert() would abort the program and I wanted to be
> able to call DebugStr() instead ;-)

Good idea, and one we should put to use for Boost.