[Thread] Win32 exception handling
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate. I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave, On Tue, Nov 25, 2008 at 6:05 PM, David Abrahams <dave@boostpro.com> wrote:
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
The catch clause in the code is a good thing in my opinion because of 15.3.9 in the standard which states: "If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined" I typically want my destructors to run, so I prefer to have this catch block present. The alternative is to implement catch (...) in all functions run by thread. The disadvantage is, of course, that debugging is more awkward after an unhandled exception. When using Visual Studio I have found it useful to configure the exceptions to stop when thrown, although this might prove impractical for some. Due to the my perceived necessity to guarantee stack unwinding, I propose that "leaking" the exception is ok if by "leaking" we mean to optionally rethrow.
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
Do you mean conforming to the current C++ standard or to a newer thread proposal? I believe that section 15.3.9 means that either order of stack unwinding and termination is allowable.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Neil Groves
on Tue Nov 25 2008, "Neil Groves" <neil-AT-grovescomputing.com> wrote:
Dave,
On Tue, Nov 25, 2008 at 6:05 PM, David Abrahams <dave@boostpro.com> wrote:
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
The catch clause in the code is a good thing in my opinion because of 15.3.9 in the standard which states: "If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined"
Well, good or not, that makes it required if we want to conform to the upcoming standard. A leaked exception under Win32/MSVC does not cause terminate() to be called. However, it might be good to provide a non-conforming mode for this purpose.
I typically want my destructors to run, so I prefer to have this catch block present. The alternative is to implement catch (...) in all functions run by thread. The disadvantage is, of course, that debugging is more awkward after an unhandled exception. When using Visual Studio I have found it useful to configure the exceptions to stop when thrown, although this might prove impractical for some.
That's fine when you're running under the debugger, but if you want good post-mortem information and/or JIT debugging, you need to leak the exception or use the set_se_handler trick, which -- I think -- only helps for segfaults and the like, not C++ exceptions.
Due to the my perceived necessity to guarantee stack unwinding, I propose that "leaking" the exception is ok if by "leaking" we mean to optionally rethrow.
That's not what I meant.
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
Do you mean conforming to the current C++ standard or to a newer thread proposal?
There's no threading in the current standard; I meant the CD.
I believe that section 15.3.9 means that either order of stack unwinding and termination is allowable.
I don't know what you mean by that. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave, On Tue, Nov 25, 2008 at 7:57 PM, David Abrahams <dave@boostpro.com> wrote:
on Tue Nov 25 2008, "Neil Groves" <neil-AT-grovescomputing.com> wrote:
Dave,
On Tue, Nov 25, 2008 at 6:05 PM, David Abrahams <dave@boostpro.com> wrote:
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
The catch clause in the code is a good thing in my opinion because of 15.3.9 in the standard which states: "If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined"
Well, good or not, that makes it required if we want to conform to the upcoming standard. A leaked exception under Win32/MSVC does not cause terminate() to be called. However, it might be good to provide a non-conforming mode for this purpose.
Agreed. It seems that a debugging mode would be desirable. I appear to be in the minority for prefering the catch(...) to be in the code so that stack unwinding is performed and destructors are executed. Perhaps we could implement something on Windows using imagehlp to take a snapshot of the stack and thereby have our destructors executed and capture the stack information?
I typically want my destructors to run, so I prefer to have this catch
block
present. The alternative is to implement catch (...) in all functions run by thread. The disadvantage is, of course, that debugging is more awkward after an unhandled exception. When using Visual Studio I have found it useful to configure the exceptions to stop when thrown, although this might prove impractical for some.
That's fine when you're running under the debugger, but if you want good post-mortem information and/or JIT debugging, you need to leak the exception or use the set_se_handler trick, which -- I think -- only helps for segfaults and the like, not C++ exceptions.
Agreed.
Due to the my perceived necessity to guarantee stack unwinding, I propose that "leaking" the exception is ok if by "leaking" we mean to optionally rethrow.
That's not what I meant.
I didn't think you did really! I just really want my destructors to run!
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
Do you mean conforming to the current C++ standard or to a newer thread proposal?
There's no threading in the current standard; I meant the CD.
Of course.
I believe that section 15.3.9 means that either order of stack unwinding and termination is allowable.
I don't know what you mean by that.
I meant that section 15.3.9 allows the std::terminate call to occur in the event of an unhandled exception without unwinding the call-stack, but it also allows stack unwinding followed by std::terminate. This was also why I asked about which standard you were asking about, since I was not sure if you were checking compliance of the exception handling specific parts or the threading parts. I am now though.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of David Abrahams
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions.
Are you referring specifically to the catch(...) in thread_start_function?
They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
Doesn't the call to std::terminate() from that catch(...) block result in the application dying in a manner which allows the debugger to intervene? -Chris
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception. For that reason, among others, it's good to avoid the catch/rethrow construct. The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586 Matt Chris Newbold wrote:
From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of David Abrahams
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions.
Are you referring specifically to the catch(...) in thread_start_function?
They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
Doesn't the call to std::terminate() from that catch(...) block result in the application dying in a manner which allows the debugger to intervene?
-Chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Matt, On Tue, Nov 25, 2008 at 7:01 PM, Matt Gruenke <mgruenke@intellivid.com>wrote:
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
For that reason, among others, it's good to avoid the catch/rethrow construct.
Your point is completely valid, but because 15.3.9 allows the stack to not be unwound this might mean that destructors do not run that would release resources do not get cleaned up by process termination. Hence there are valid reasons to do both. I expect this is why the standard explicitly allows both arrangements.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
Matt
I suppose the only sensible solution is to allow both solutions in boost.thread too. Neil Groves
Chris Newbold wrote:
From: boost-bounces@lists.boost.org [mailto:boost-
bounces@lists.boost.org] On Behalf Of David Abrahams
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions.
Are you referring specifically to the catch(...) in thread_start_function?
They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
Doesn't the call to std::terminate() from that catch(...) block result in the application dying in a manner which allows the debugger to intervene?
-Chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Tue Nov 25 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote:
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
Right, that's essentially the MSVC/Win32 behavior I'm describing.
For that reason, among others, it's good to avoid the catch/rethrow construct.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Nov 25, 2008 at 11:59 AM, David Abrahams <dave@boostpro.com> wrote:
on Tue Nov 25 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote:
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
Right, that's essentially the MSVC/Win32 behavior I'm describing.
For that reason, among others, it's good to avoid the catch/rethrow construct.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
Maybe I'm missing something but what in the upcoming standard requires the catch(...)? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 9:16 PM Subject: Re: [boost] [Thread] Win32 exception handling
On Tue, Nov 25, 2008 at 11:59 AM, David Abrahams <dave@boostpro.com> wrote:
on Tue Nov 25 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote:
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
Right, that's essentially the MSVC/Win32 behavior I'm describing.
For that reason, among others, it's good to avoid the catch/rethrow construct.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
Maybe I'm missing something but what in the upcoming standard requires the catch(...)?
Emil, Can the Boost.Exception library be useful to recover the stackframe from the time it was thrown ? Vicente
On Tue, Nov 25, 2008 at 12:23 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Emil,
Can the Boost.Exception library be useful to recover the stackframe from the time it was thrown ?
The problem is that the debugging information we're talking about is gone once you catch the exception. It might be possible to capture stack information and store it in the exception object before it is passed to throw, but that would A) require platform-specific (even ABI-specific) hacks, and B) in my opinion it would have unreasonable overhead (consider that usually throwing an exception isn't a bug, while such information is only useful for debugging purposes.) OTOH, it is relatively easy for the implementation to display this information if catch(...) is not used. I don't see what's the problem with this and I don't understand why boost::thread has a catch(...) -- after all, if I wanted a catch(...) I'd write one, right? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Tue Nov 25 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
On Tue, Nov 25, 2008 at 11:59 AM, David Abrahams <dave@boostpro.com> wrote:
on Tue Nov 25 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote:
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
Right, that's essentially the MSVC/Win32 behavior I'm describing.
For that reason, among others, it's good to avoid the catch/rethrow construct.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586>>
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
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. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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. In other words, if an exception propagates out of the thread function, that's a bug. In this case, the call to terminate() is reasonable. As a bonus, a standard-conforming implementation can also display a stack trace. Anyway, automatic catch(...) in boost::thread is not necessary IMO. 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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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
On Tue, Nov 25, 2008 at 1:11 PM, David Abrahams <dave@boostpro.com> wrote:
It is necessary for conformance in many popular implementations because they have no other way to ensure a call to terminate().
Ah I get it! You mean, popular implementations of thread functionality, not the compiler itself. :)
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.
I'm not sure it should be trying to do that. I'd rather have it fallback to what the implementation happens to do in this situation; after all, that behavior is implementation- and os-specific and should make sense. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
David Abrahams:
"If no matching handler is found, the function std::terminate() is called; ..."
This wording is also present in C++03, if I'm not mistaken, and MSVC does obey it, for all threads. There's an additional twist there though; set_terminate is per-thread in MSVC (7.1 at least).
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. -- AlisdairM
On Tue, Nov 25, 2008 at 4:09 PM, AlisdairM <nntp.alisdairm@gmail.com> 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
Emil Dotchevski:
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.
This is a false dilemma. There is a third option: use catch(...) only when the compiler doesn't call terminate() itself.
On Tue, Nov 25, 2008 at 4:40 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Emil Dotchevski:
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.
This is a false dilemma. There is a third option: use catch(...) only when the compiler doesn't call terminate() itself.
Naturally -- why'd boost::thread use catch(...) otherwise? To call terminate() "better"? :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski:
On Tue, Nov 25, 2008 at 4:40 PM, Peter Dimov <pdimov@pdimov.com> wrote: ...
This is a false dilemma. There is a third option: use catch(...) only when the compiler doesn't call terminate() itself.
Naturally -- why'd boost::thread use catch(...) otherwise? To call terminate() "better"? :)
But the current Boost.Thread implementation always uses catch(...), even on compilers that do call terminate(), such as MSVC. -- Peter Dimov http://www.pdplayer.com
On Tue, Nov 25, 2008 at 19:32, Emil Dotchevski <emil@revergestudios.com> wrote:
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.
Why wouldn't an empty exception specification work? It seems like the unexpected() call should call terminate() without ever doing an explicit catch (...). Of course, this depends on the compiler implementing exception specifications properly, and since Visual C++ doesn't ("However, if an exception is thrown out of a function marked throw(), the Visual C++ compiler will not call unexpected" ~ http://msdn.microsoft.com/en-us/library/wfa0edys.aspx ), it might give exactly what Dave's contact wants. ~ Scott
From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Tuesday, November 25, 2008 2:59 PM
on Tue Nov 25 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote:
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
Right, that's essentially the MSVC/Win32 behavior I'm describing.
Now that I think this through fully, I too have often cursed "unnecessary" top-level catch(...) blocks for exactly the same reason: they often result in the loss of context for the exception.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_ id=7586&atid=357586
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
It seems like they've left some wiggle room, though, by not specifying whether or not the stack is unwound or not. Ideally, it wouldn't be (best for diagnostics), but I don't know of any platform that simultaneously allows you to write catch(...) and _not_ lose the context... -Chris
David Abrahams wrote: [...]
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
IMO, that's very idiotic, if true. User code doesn't expect some exception: suppose the case when caller has made precautions so that this or that operation's documented exception shall not occur in context established by caller. And operation suddenly throws... that means broken program state... and you insist on unwinding. Nonsense! The program shall abort() ASAP at throw point. Cleanup for eventual external resources (if it really matters/shall be reliable) shall be done by another higher level (isolated) program (with clean state) acting as watchdog (broken state program can not be trusted to do any cleanup of external resources). Cleanup for stack frames ("locals") makes even less sense, given broken program state (possibly including stack frames). Dejavu... http://lists.boost.org/Archives/boost/2003/10/54064.php regards, alexander.
----- Original Message ----- From: "Alexander Terekhov" <terekhov@web.de> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 10:17 PM Subject: Re: [boost] [Thread] Win32 exception handling
David Abrahams wrote: [...]
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
IMO, that's very idiotic, if true.
User code doesn't expect some exception: suppose the case when caller has made precautions so that this or that operation's documented exception shall not occur in context established by caller.
And operation suddenly throws... that means broken program state... and you insist on unwinding. Nonsense! The program shall abort() ASAP at throw point. Cleanup for eventual external resources (if it really matters/shall be reliable) shall be done by another higher level (isolated) program (with clean state) acting as watchdog (broken state program can not be trusted to do any cleanup of external resources). Cleanup for stack frames ("locals") makes even less sense, given broken program state (possibly including stack frames).
Why do you associate an exception to a broken program state? Vicente
"vicente.botet" wrote: [...]
Why do you associate an exception to a broken program state?
Example: Suppose that your operation's documentation says that it may need heap unless the caller provides X() amount of memory via void * parameter to be used instead of heap (void * p is not zero). #include <new> void operation(void * p) throw (std::bad_alloc); // may throw if p == 0 size_t X(); #include <new> int main() { if (void * const p = new(std::nothrow) char [X()]) { // ... nothrow operation(p); } else { // ... nothrow } // ... nothrow } What if your operation still throws std::bad_alloc? regards, alexander.
----- Original Message ----- From: "Alexander Terekhov" <terekhov@web.de> To: <boost@lists.boost.org> Sent: Wednesday, November 26, 2008 12:42 AM Subject: Re: [boost] [Thread] Win32 exception handling
"vicente.botet" wrote: [...]
Why do you associate an exception to a broken program state?
Example:
Suppose that your operation's documentation says that it may need heap unless the caller provides X() amount of memory via void * parameter to be used instead of heap (void * p is not zero).
#include <new>
void operation(void * p) throw (std::bad_alloc); // may throw if p == 0
size_t X();
#include <new>
int main() { if (void * const p = new(std::nothrow) char [X()]) { // ... nothrow operation(p); } else { // ... nothrow } // ... nothrow }
What if your operation still throws std::bad_alloc?
Why the operation can throw std::bad_alloc? You have used std::nothrow, so Vicente
So, your point is that broken program state can result in an exception incorrectly being thrown? But it can also result in any number of other actions. I don't see where you're going with this. Matt Alexander Terekhov wrote:
"vicente.botet" wrote: [...]
Why do you associate an exception to a broken program state?
[... example ...]
Why the operation can throw std::bad_alloc?
Due to broken program state.
regards, alexander.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Alexander Terekhov" <terekhov@web.de> To: <boost@lists.boost.org> Sent: Wednesday, November 26, 2008 2:32 PM Subject: Re: [boost] [Thread] Win32 exception handling
"vicente.botet" wrote: [...]
Why do you associate an exception to a broken program state?
[... example ...]
Why the operation can throw std::bad_alloc?
Due to broken program state.
OK, broken program state can result in an exception thrown, but the opossit is not true. The user is unable to make a difference when the exception has been thrown because a broken program state or because of the logic. In addition, if the program is in a broken state, it is even more possible that the program crashes than it throw an exception. My preceding question should be: Why do you associate a broken program state with an exception? So if the user program can throw exceptions and most of them can, the user need to catch the exception in order to unwind the local variables. Vicente
"vicente.botet" wrote: [...]
In addition, if the program is in a broken state, it is even more possible that the program crashes than it throw an exception.
So do you really want to unwind the stack on program crashes (instead of aborting at crash point) as well?
My preceding question should be: Why do you associate a broken program state with an exception?
Because that particular exception is unexpected in the established context. If you believe that you still somehow must handle it then you can add catch(...) yourself but don't insist on catch(...) and unwinding mandatory made by the implementation (or Boost.Thread for that matter). regards, alexander.
on Tue Nov 25 2008, Alexander Terekhov <terekhov-AT-web.de> wrote:
David Abrahams wrote: [...]
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
IMO, that's very idiotic, if true.
I think what I wrote was misleading. I should have written that it requires the catch(...) on any platform that doesn't automatically call terminate() as part of the response when an exception escapes from a thread. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Tue Nov 25 2008, Alexander Terekhov <terekhov-AT-web.de> wrote:
David Abrahams wrote: [...]
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
IMO, that's very idiotic, if true.
I think what I wrote was misleading. I should have written that it requires the catch(...) on any platform that doesn't automatically call terminate() as part of the response when an exception escapes from a thread.
I would have thought (not checking the current draft) that the standard (still) requires terminate() when "no matching handler is found". (Note that Boost.Thread's catch(...) *IS* matching handler and so it doesn't fall under that "no matching handler is found" clause). Anyway, how could Boost.Thread call terminate() in ***main/initial*** thread on a "platform that doesn't automatically call terminate() as part of the response when an exception escapes from a thread" (main/initial thread)? No way. BTW, in my view, the response to an exception escaping the thread shall be abort() (at throw point), not terminate(). Related: (Rhetorical question.) When are you standard folks finally going to fix ES (exception specifications) and get rid of very idiotic ES' mandatory catch(...)? The current standard-mandated ES behaviour just hurts and doesn't help anyone except archaic one-phase setjmp/longjmp based "C exceptions" implementors enabled to claim compliance. regards, alexander.
At 2:59 PM -0500 11/25/08, David Abrahams wrote:
OK, great, a second data point. How do you feel about the fact that the upcoming standard requires the catch(...)?
It's back?! There was a discussion on this list in August 2005 on the pros and cons of the existence of the try/catch(...) in thread_proxy(), which seemed to end with a pretty clear consensus that it should be removed, and there was a bug report filed to do so: 1274707. (That's probably in some old bug tracking system, not the current boost trac.) The rationale was basically what's been brought up in the recent messages: better debugging is generally available on at least some common platforms if there isn't such a try/catch(...) handler. That try/catch was removed by Peter Dimov in early July 2006. It seems to have returned though, which I think is unfortunate. It might be that a native (integrated with the compiler, or otherwise using non-portable mechanisms) could provide the terminate behavior required by the current draft standard while still providing a good debugging experience, where a more or less portable thread library such as boost.thread really can't. If that's the case, my vote would be for boost.thread to be non-conforming in this specific area.
----- Original Message ----- From: "Matt Gruenke" <mgruenke@intellivid.com> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 8:01 PM Subject: Re: [boost] [Thread] Win32 exception handling
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
For that reason, among others, it's good to avoid the catch/rethrow construct.
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
When I try to open this page anerror apears. Can you post the ticket? Thanks, Vicente
vicente.botet wrote:
----- Original Message ----- From: "Matt Gruenke"
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
When I try to open this page anerror apears. Can you post the ticket?
That bug tracker is apparently obsolete. As I know of no way to gain access to my filing, here's the text: Feature Requests item #1274707, was opened at 2005-08-27 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_id=7586 Category: thread Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: William E. Kempf (bill_kempf) Summary: Remove try/catch(...) in thread.cpp:thread_proxy() Initial Comment: THE CASE AGAINST try {} catch (...) {} IN libs/thread/src/thread.cpp:thread_proxy() The only platform on which I've used boost::thread is Linux + GCC. So, on the debugging front, I can only speak to that. In this configuration (using pthreads), the behavior of an exception being allowed to propagate outside of a thread function is quite useful - you get a backtrace of the entire call sequence leading up to the throw, AND a full unwind back from that point (which looks like further entries in the call stack). However, if an exception is caught & rethrown, all of the prior call & unwind history is lost. Obviously, this also happens if an exception is caught and not rethrown - which is the current (circa version 1.33.0) behavior of thread_proxy(). I've tried a number of experiments, as well as inspecting pthreads & glibc code, and have been unsuccessful at reproducing this behavior in user code. However it's so useful that, on virtually every project where I'd like to use boost::thread, I eventually resort patching the source to remove this last-resort try/catch block. For a library to be of much practical value, debugging must not be significantly impaired (and even enhanced, where possible without significant compromises). The additional complexity of multithreaded programs makes this all the more important. I think this point stands pretty well, on its own. A more troubling aspect of this try/catch block is that the thread terminates in exactly the same way via an otherwise unhandled exception as it does when the user-supplied threadfunc exits cleanly. If the user of boost::thread didn't think to catch the particular exception in question, then it's unlikely it employed and is inspecting any other mechanism for determining whether the thread accomplished its goal. This assumption violated, it's unsafe to assume the program will continue to function correctly. Since the thread exists in the same memory space as the rest of the process (and shares library state, if not also other data structures), an unhandled exception indicates bad state in the process, or some other invalidated assumption. In fact, in non-exception-safe code, it may even produce bad state. Any of these conditions makes it unsafe to assume the program will continue to operate correctly. Finally, there's a more philosophical point that should probably be made. The primary purpose of exceptions is to provide proactive notification of program errors (as opposed to relying on return codes - which facilitate errors being silently ignored). Why should behavior of uncaught exceptions in other threads be any different than main? Yet thread_proxy() just quietly drops them on the floor. As a user, I normally expect that no unhandled exceptions were thrown, if my program runs to completion. WHAT WILL HAPPEN IF IT'S REMOVED? If the user specifically wants this behavior, it can suitably augment its user-supplied threadfunc to contain the catchall. There's nothing wrong with simply stating that the behavior of exceptions that propagate outside threadfunc is undefined. While changing this might "break" some existing code, it's really quite likely that code is already broken - though the user simply doesn't know it. IMO, there's nothing wrong with libraries evolving to detect more errors and invalid conditions. CONCLUSION In summary, I believe the current behavior is: 1. Dangerous - hides program errors in a most un-exception-like manner. 2. Unfriendly - defeats useful debugging functionality, on some platforms. 3. Surprising - users don't expect libraries to inhibit propagation of their exceptions. 4. Unnecessary - the user can easily supply this behavior, if desired.
on Wed Nov 26 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote:
vicente.botet wrote:
----- Original Message ----- From: "Matt Gruenke"
The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586>> When I try to open this page anerror apears. Can you post the ticket?
That bug tracker is apparently obsolete. As I know of no way to gain access to my filing, here's the text:
Feature Requests item #1274707, was opened at 2005-08-27 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_id=7586
Category: thread Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: William E. Kempf (bill_kempf) Summary: Remove try/catch(...) in thread.cpp:thread_proxy()
Initial Comment:
THE CASE AGAINST try {} catch (...) {} IN libs/thread/src/thread.cpp:thread_proxy()
That ticket has been reincarnated at http://svn.boost.org/, as #476, which someone closed as fixed(!) and worse, there seems to be a bug in Trac that prevents the ticket from being viewed directly (http://trac.edgewall.org/ticket/7840). Fortunately, you can still see the whole description (but none of the updates) here: https://svn.boost.org/trac/boost/query?status=closed&summary=~thread_proxy&col=id&col=summary&col=status&col=owner&col=type&col=milestone&col=version&col=reporter&order=priority&row=description Which I think matches what was was pasted here:
The only platform on which I've used boost::thread is Linux + GCC. So, on the debugging front, I can only speak to that. In this configuration (using pthreads), the behavior of an exception being allowed to propagate outside of a thread function is quite useful - you get a backtrace of the entire call sequence leading up to the throw, AND a full unwind back from that point (which looks like further entries in the call stack).
Does anyone know if it also call std::terminate() ?
A more troubling aspect of this try/catch block is that the thread terminates in exactly the same way via an otherwise unhandled exception as it does when the user-supplied threadfunc exits cleanly. If the user of boost::thread didn't think to catch the particular exception in question, then it's unlikely it employed and is inspecting any other mechanism for determining whether the thread accomplished its goal. This assumption violated, it's unsafe to assume the program will continue to function correctly.
I disagree. It is rare that an exception carries information that determines how it needs to be handled. Usually, the same recovery and/or unwinding actions apply to all exceptions.
Since the thread exists in the same memory space as the rest of the process (and shares library state, if not also other data structures), an unhandled exception indicates bad state in the process, or some other invalidated assumption.
I don't think an unhandled exception means anything other than that there was no handler to catch it.
In fact, in non-exception-safe code, it may even produce bad state. Any of these conditions makes it unsafe to assume the program will continue to operate correctly.
Finally, there's a more philosophical point that should probably be made. The primary purpose of exceptions is to provide proactive notification of program errors
If by "program errors" you mean "inability to satisfy postconditions, as when necessary resources have been exhausted," then yes. If you mean bugs, then no.
(as opposed to relying on return codes - which facilitate errors being silently ignored). Why should behavior of uncaught exceptions in other threads be any different than main?
It should not. I think the author's assumption was that the system's runtime library already provided the standard-mandated call to terminate() when an exception escapes from main(), but since the standard didn't say anything about thread-termination, one can't count on a call to terminate() when an exception escapes from a thread.
Yet thread_proxy() just quietly drops them on the floor.
I don't think there is a thread_proxy in the current Boost.Thread anymore. At least, rgrep isn't finding it for me. And the existing catch(...) blocks I did find call terminate().
As a user, I normally expect that no unhandled exceptions were thrown, if my program runs to completion.
WHAT WILL HAPPEN IF IT'S REMOVED?
If the user specifically wants this behavior, it can suitably augment its user-supplied threadfunc to contain the catchall. There's nothing wrong with simply stating that the behavior of exceptions that propagate outside threadfunc is undefined.
While changing this might "break" some existing code, it's really quite likely that code is already broken - though the user simply doesn't know it. IMO, there's nothing wrong with libraries evolving to detect more errors and invalid conditions.
CONCLUSION
In summary, I believe the current behavior is: 1. Dangerous - hides program errors in a most un-exception-like manner. 2. Unfriendly - defeats useful debugging functionality, on some platforms. 3. Surprising - users don't expect libraries to inhibit propagation of their exceptions. 4. Unnecessary - the user can easily supply this behavior,
I mostly agree. There's only the issue of ensuring calls to terminate when the user want CD-conforming behavior, and as Peter D. points out, on Win32/MSVC at least, that doesn't have to be an issue. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At 12:19 PM -0500 11/26/08, David Abrahams wrote:
That ticket has been reincarnated at http://svn.boost.org/, as #476, which someone closed as fixed(!)
Presumably because it *was* fixed, by Peter Dimov, circa late June / early July 2006. It appears that the try/catch has been reincarnated, as part of the major rewrite of boost.thread that has occurred since then.
on Wed Nov 26 2008, Kim Barrett <kab.conundrums-AT-verizon.net> wrote:
At 12:19 PM -0500 11/26/08, David Abrahams wrote:
That ticket has been reincarnated at http://svn.boost.org/, as #476, which someone closed as fixed(!)
Presumably because it *was* fixed, by Peter Dimov, circa late June / early July 2006. It appears that the try/catch has been reincarnated, as part of the major rewrite of boost.thread that has occurred since then.
All the more reason to revert it to Peter's approach if we can. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Wed Nov 26 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote
THE CASE AGAINST try {} catch (...) {} IN libs/thread/src/thread.cpp:thread_proxy()
That ticket has been reincarnated at http://svn.boost.org/, as #476, which someone closed as fixed(!) and worse, there seems to be a bug in Trac that prevents the ticket from being viewed directly (http://trac.edgewall.org/ticket/7840). Fortunately, you can still see the whole description (but none of the updates) here:
Which I think matches what was was pasted here:
A more troubling aspect of this try/catch block is that the thread terminates in exactly the same way via an otherwise unhandled exception as it does when the user-supplied threadfunc exits cleanly. If the user of boost::thread didn't think to catch the particular exception in question, then it's unlikely it employed and is inspecting any other mechanism for determining whether the thread accomplished its goal. This assumption violated, it's unsafe to assume the program will continue to function correctly.
I disagree. It is rare that an exception carries information that determines how it needs to be handled. Usually, the same recovery and/or unwinding actions apply to all exceptions.
I think what I meant was that an unhandled exception usually has the effect of leaving the program in an invalid state, either by leaving datastructures in an inconsistent state or simply by failing to satisfy other sorts of internal conditions for continued and correct operation of the program. Take the example of a program which uses a dedicated thread for file I/O. Even if an unhandled exception does trigger all the local destructors for that thread, it's likely that the rest of the program will still eventually block. It would be preferable to terminate the program, once the exception occurs. That at least allows the error to be handled at the next level (i.e. outside the process). I think this point (i.e. that unhandled exception should *somehow* trigger program termination) is no longer in dispute.
(as opposed to relying on return codes - which facilitate errors being silently ignored). Why should behavior of uncaught exceptions in other threads be any different than main?
It should not. I think the author's assumption was that the system's runtime library already provided the standard-mandated call to terminate() when an exception escapes from main(), but since the standard didn't say anything about thread-termination, one can't count on a call to terminate() when an exception escapes from a thread.
The original implementation did NOT call std::terminate(). It caught the exception and proceeded to terminate the thread in exactly the same way as if the thread function had returned. That was one of my complaints, in the original RFE. I discovered it upon investigating a problem in which some of my threads seemed to be prematurely exiting.
CONCLUSION
In summary, I believe the current behavior is: 1. Dangerous - hides program errors in a most un-exception-like manner. 2. Unfriendly - defeats useful debugging functionality, on some platforms. 3. Surprising - users don't expect libraries to inhibit propagation of their exceptions. 4. Unnecessary - the user can easily supply this behavior,
I mostly agree. There's only the issue of ensuring calls to terminate when the user want CD-conforming behavior, and as Peter D. points out, on Win32/MSVC at least, that doesn't have to be an issue.
Yeah, it sounds like my bug is only partially relevant to the current implementation. Matt
----- Original Message ----- From: "Matt Gruenke" <mgruenke@intellivid.com> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 8:01 PM Subject: Re: [boost] [Thread] Win32 exception handling
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
For that reason, among others, it's good to avoid the catch/rethrow construct.
Please could some one explain in which cases the destructors of all the locals are not executed? Can the stack-frame be recovered in some way just before the destructors are called? Thanks, Vicente
on Tue Nov 25 2008, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
----- Original Message ----- From: "Matt Gruenke" <mgruenke@intellivid.com> To: <boost@lists.boost.org> Sent: Tuesday, November 25, 2008 8:01 PM Subject: Re: [boost] [Thread] Win32 exception handling
Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception.
For that reason, among others, it's good to avoid the catch/rethrow construct.
Please could some one explain in which cases the destructors of all the locals are not executed?
When the program exits due to an uncaught exception, it is up to the compiler vendor whether those locals will be destroyed. If you want to portably ensure destruction, put a catch(...) in main. If you want to portably ensure non-destruction in case of an uncaught exception, you're out of luck. You may of course have knowledge about your particular compiler.
Can the stack-frame be recovered in some way just before the destructors are called?
That's dependent on your specific compiler implementation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
vicente.botet wrote:
Can the stack-frame be recovered in some way just before the destructors are called?
This may be off-topic but the logging library I'm working on allows to embed the calling stack information into the thrown exception. The scope names must be marked up explicitly, though, but that's a portable solution. More on this is available here: http://tinyurl.com/67ttlq
on Tue Nov 25 2008, Chris Newbold <Chris.Newbold-AT-mathworks.com> wrote:
From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of David Abrahams
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions.
Are you referring specifically to the catch(...) in thread_start_function?
Yes
They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
Doesn't the call to std::terminate() from that catch(...) block result in the application dying in a manner which allows the debugger to intervene?
Yes, but under Win32/MSVC you lose all the backtrace information between the throw point and the catch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
"David Abrahams" <dave@boostpro.com> wrote in message news:87prkj65ri.fsf@mcbain.luannocracy.com...
whether a preprocessor switch to allow exceptions to leak would be a good idea?
For me, yes, regardless on whether this would be unconforming. When something really unexpected happens, the best for us is to get a crash dump (from winqual or written manually). Then it is important not to lose any context, so that dump would be useful. We prefer to to catch any SEH exceptions, not to set SEH translator, and compile with /EHcs. Destructors are not called, memory is not deallocated. WerUnregisterMemoryBlock, which is called from destructor is not called. For C++ exception we avoid catch(...) and exception specification (even throw() in destructor), just for same reason - immediately crash and send dump to winqual is the best thing when something unexpected happens. However, for other projects other strategy will be better.
David Abrahams <dave@boostpro.com> writes:
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
I have removed the catch clause on trunk, revision 49969. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
on Thu Nov 27 2008, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
David Abrahams <dave@boostpro.com> writes:
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
I have removed the catch clause on trunk, revision 49969.
Thank you, Anthony! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (14)
-
Alexander -
Alexander Terekhov -
AlisdairM -
Andrey Semashev -
Anthony Williams -
Chris Newbold -
David Abrahams -
Emil Dotchevski -
Kim Barrett -
Matt Gruenke -
Neil Groves -
Peter Dimov -
Scott McMurray -
vicente.botet