Re: [boost] [Thread] Win32 exception handling

Subject: Re: [boost] [Thread] Win32 exception handling
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-11-25 19:32:06

On Tue, Nov 25, 2008 at 4:09 PM, AlisdairM <nntp.alisdairm_at_[hidden]> wrote:
> David Abrahams wrote:
>
>> 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.
>
> Note that this is essentally the same rule as when the exception
> handling system fails today, only transferred to all threads rather
> than just the main thread.  in other words, if this works the way your
> customers intend today by compiler magic, that same magic should be
> implied for additional threads in 0x, and thus has nothing to do with a
> requirement to catch(...) in the thread library itself.
>
> My understanding is that thread should *not* have the catch, allowing
> the thread to terminate as per clause 15, and that future and
> packaged_task are the means to catch and transport exceptions between
> threads.

That was the point I made but Dave's point is different.

Suppose your compiler doesn't call terminate() when exceptions
propagate out of thread functions but you want to implement
boost::thread in a way that's conformant with the standard (so, you
are not the compiler, and can't use compiler magic.)

The only way to do this is to catch(...) and then call terminate().
The problem is, if you catch(...) you've just killed the stack trace
your compiler could give you.

So the question is what's better for boost::thread, to conform to the
C++ standard -- which in the scenario I outlined and Dave had in mind
can only be done using catch(...) -- or to leave conformance up to the
compiler, meaning terminate() may not be called when it should, but
assuming that that is a bug (which may not be the case, as Dave
pointed out) you'll get a better error message.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode