on Tue Nov 25 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
On Tue, Nov 25, 2008 at 12:26 PM, David Abrahams <dave@boostpro.com> wrote:
on Tue Nov 25 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Maybe I'm missing something but what in the upcoming standard requires the catch(...)?
The requirement that terminate() be called when the exception isn't otherwise caught. Of course you can do it with "compiler magic" because the standard doesn't specify an implementation. Practically speaking, though, it means a catch(...) in the library.
I don't follow.
It means that no exception should propagate out of the thread function.
It means more than that. It means that terminate() is called. "If no matching handler is found, the function std::terminate() is called; ..."
In other words, if an exception propagates out of the thread function, that's a bug.
It's only a bug if your program doesn't expect to call std::terminate() in that case. If terminate() is your desired result, it's not a bug.
In this case, the call to terminate() is reasonable. As a bonus, a standard-conforming implementation can also display a stack trace.
Yes, but catch(...) will prevent many existing implementations from displaying a useful stack trace.
Anyway, automatic catch(...) in boost::thread is not necessary IMO.
It is necessary for conformance in many popular implementations because they have no other way to ensure a call to terminate().
To me that's like having an automatic catch(...) in main(). This doesn't mean that it's always a bad idea, only that the decision to use catch(...) is outside of the scope of boost::thread.
Not if Boost.Thread is trying to conform to the CD. -- Dave Abrahams BoostPro Computing http://www.boostpro.com