Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 17:56:02

--- 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.
> > general I'd consider such catch blocks, especially in library
> > to be a bad idea in any event.
> Especially in library code. Applications often need to do this as a
> 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".

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

Yes, it is.
> > Eating the exception is a good example of not playing nice.
> > 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.

That's the approach discussed earlier. Alexander now seems to think
the design is flawed and possibly not valid C++, but I'm not sure why
he thinks this yet.
> > > I didn't think otherwise. I am just trying to head off
> > FUD in case
> > > it's looming in the background. I'm a little obsessive about
> > 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
> > it any way, it just means I get a little more careful and
> 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
> 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
> 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 ;). Have you considered writing a book on this
subject? :)

Bill Kempf

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