|
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.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk