Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 23:41:51

----- Original Message -----
From: "Tom Becker" <voidampersand_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, January 14, 2002 10:22 PM
Subject: [boost] Re: first sight

> Dave's example of needing to eat all exceptions that might come from
> a plug-in is good. Another example is with C++ code implementing a
> callback that is called from non-C++ code such as the operating
> system. Rolling up the operating system's stack without its consent
> is bad, so a well-written callback will catch all exceptions before
> returning. In general, eating all exceptions is necessary on
> boundaries with external code that may not be written in C++, or that
> may be in C++ but using a different ABI. I think there are other
> cases where catching all exceptions can be justified in terms of
> program logic, but this is one where it's absolutely required.

Yes, that case is an even more common one than the one I mentioned.

> I'm not worried about library code eating thread cancellation
> exceptions. The library code has to return sometime, and eventually
> the thread will hit another checkpoint and it can throw another
> cancellation exception. All the mechanism has to do is not clear the
> appropriate flag until the thread is fully canceled. There is little
> need to force the cancellation exceptions to automatically rethrow
> themselves. In fact, if I have an application where a fair amount of
> work needs to be done in order to make the thread state safe to clean
> up, being able to stop a cancellation could be a very useful feature.

Wow, that's a compelling argument! I also like it because it doesn't feel
like you'd have to fight the language to implement it, the way the "must
always propogate" approach does.


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