Re: [boost] Re: first sight

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 17:44:03

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>

> > I think that if you can disable cancellation efficiently and
> mutex_lock only
> > throws cancellation exceptions, then there's no problem making
> mutex_lock a
> > cancellation point, since disabling cancellation effectively makes
> it
> > nothrow.
> >
> > If you can't disable cancellation efficiently (or, for example, if
> that
> > requires a mutex! - but I don't see why it would; that should be
> > thread-local), then the problem gets more complicated.
>
> I believe efficiency was the rationale they used, if I read the
> snippet correctly.

That was not my impression, FWIW. They made no mention of it anyway.

> > 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.

> Like I've said before, I'm probably
> worrying too much about this *possible* problem.

Since we don't really have any alternatives, I think you are ;-). It appears
to be the best we can do.

> Eating the exception is a good example of not playing nice.  That's
> why I favor some mechanism that either prevents the user from
> catching the exception, or that insures the exception is rethrown.

Me, too, if it's possible. Is it, though? I guess you can check
uncaught_exception and throw in the destructor if it returns false.

> > I didn't think otherwise. I am just trying to head off exception-
> FUD in case
> > it's looming in the background. I'm a little obsessive about that,
> sorry!
>
> Well, there is a bit of FUD here.  Exception safety makes me
> nervous.  It's a black art, IMHO, and I often worry that a design
> will wreak havoc in this area.  That won't prevent me from designing
> it any way, it just means I get a little more careful and paranoid.

Care is always good, and whether it's a black art or not is clearly a matter
of personal opinion. However, it is a very disempowering opinion to hold.
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 ;^) ;^)

-Dave