Re: first sight

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 
assumes
> > > > an "error" occurred could also be considered a bug in this 
case.
> > 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 
MT
> > application using our library, which is something I can live with 
as
> > 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 
exceptions
> 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 
about
> > > exception-safety. In fact, the issues are mostly the same as 
they
> > 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 
just
> > means I treat things more carefully when exceptions directly 
effect
> > the design.  Most of the FUD involved in this for me comes from 
the
> > 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 
particular,
> 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