Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-15 10:33:06

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> To: <boost_at_y...>
> Sent: Monday, January 14, 2002 5:56 PM
> Subject: [boost] Re: first sight
> > --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > >
> > > ----- Original Message -----
> > > From: "bill_kempf" <williamkempf_at_h...>
> > > > > You mean, "may catch(...) and fail to rethrow?"
> > > >
> > > > Mostly, yes, though a catch(...) and some operation that
> > > > an "error" occurred could also be considered a bug in this
> > In
> > > > general I'd consider such catch blocks, especially in library
> > code,
> > > > to be a bad idea in any event.
> > >
> > > Especially in library code. Applications often need to do this
as a
> > safety
> > > net in order to deal with and report unanticipated errors.
> >
> > And it's a simple violation of the contract if they do this in a
> > application using our library, which is something I can live with
> > the library "vendor".
> When I say "applications" I'm basically talking about the "main"
thread, in
> main() or some equivalent top-level function. Would that still be a
> violation?

When I say "applications" I mean the code under the programmer's
control (as opposed to third party libraries). If the programmer
uses Boost.Threads, and doesn't "play by the rules" of Boost.Threads,
that's a violation of the contract and he has no one to blame but
himself. When the bug is detected he simply must fix it.

When this occurs in third party libraries (who have no idea that
Boost.Threads is being used) it becomes much more difficult for our
poor programmer to fix or work around the problem. (Note that third
party libraries won't directly call any cancellation points. This
would have to occur in callbacks, so there *may* be a means for our
theoretical programmer to work around the problem.)

> If so, there's a way out, but you have to let people catch our
> explicitly
> catch(thread_cancellation const& e) {throw;}
> catch(...)

Yes. Our direct users should always be able to handle things
correctly (though it may require extensive code changes to existing
applications). It's only the corner cases involving third party
libraries that cause problems.

> > That mindset tends to prevent people from thinking effectively
> > > exception-safety. In fact, the issues are mostly the same as
> > were for
> > > your more "traditional" error-handling schemes, at least if you
> > exclude the
> > > scheme where errors are ignored. If you'd like to discuss
> > the /science/ of
> > > exception-safety I'll be happy to help you to arrive at a more
> > productive
> > > relationship with exceptions ;^) ;^)
> >
> > I don't think it's that disempowering, at least in my case. It
> > means I treat things more carefully when exceptions directly
> > the design. Most of the FUD involved in this for me comes from
> > fact that there are still "dark corners" in the "art" that I'm not
> > versed in. So any help you can provide would be well
> > appreciated ;).
> To which "dark corners" are you referring? We can start there.

The next time I encounter one I'll start a conversation with you in
private e-mail. :)
> > Have you considered writing a book on this
> > subject? :)
> Yes, I had serious plans to do it, and interest from AW, but:
> 1. The appearance of Herb's book was a major discouragement. In
> the title seemed to claim the domain.

I'm not familiar with this book. Got a BN or Amazon link to it?
> 2. Whenever I think about it, I think "there's really not that much
to say".
> I know that's not really true; I have loads of posts to c.l.c++.m
which I
> could distill, but I seem to have a much easier time saying "no,
no, don't
> go that way, the truth is over here!", than whatever is required
for a book.

There's probably a lot to say about it, even if you formed the book
with chapters starting with some idea that someone's posted and spend
the rest of the chapter explaining why one shouldn't "go that way".
Actually, a format along the lines of EC++ and MEC++ would be perfect
for this.
> 3. I've barely got time to do the stuff I can get paid real money
for ;-)

*laughs* And yet you spend time here, where you get pain _no_
money? The book would be at least as helpful as any of our
contributions here, and it would at least pay "fake" money ;).

I understand though. There's only so many hours in the day. I found
it very difficult to find the time to write a magazine article for
CUJ recently, and a book would be many factors worse.
> If my current gig works out for me, though, maybe I'll take some
time to
> write the book later this year.

If you do, I'll be the first in line to buy it.

Bill Kempf

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