The Windows docs do specify what happens with an uncaught exception: http://msdn.microsoft.com/en-us/library/ac9f67ah(VS.80).aspx And this document implies (very strongly, IMO) that this applies on any thread (given that it states that terminating the current thread is a viable option). Similarly the docs for set_terminate state that is operates on multiple threads: http://msdn.microsoft.com/en-us/library/t6fk7h29(VS.80).aspx The MS implementation of C++ exceptions is directly based on SEH, and the behaviour of uncaught SEH is well defined. Have to admit I'm not sure it's actually defined to be based on SEH though. There are also big problems with using catch(...) with VC if anyone makes attempts to handle SEH exceptions as C++ exceptions (and boost::test requires us to do this :( ). I know that I'm asking for a platform specific change, but the pain of this catch on Windows is quite significant. As a trivial example: DWORD WINAPI ThreadProc( LPVOID lpParameter ) { throw 14; } void function() { throw 14; } int main(int argc, char * argv[]) { // Comment out one or the other, so much easier than command line args CreateThread( NULL, 0, ThreadProc, NULL, 0, NULL ); //boost::thread t( function ); Sleep( 1000000 ); } With the native call I get straight into the JIT handler, and windbg can report the line calling "throw 14". With the boost::thread call I get told that the application has requested that it be terminated in an unusual way - and the debugger knows nothing about my exception. Jim
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Anthony Williams Sent: 08 May 2008 09:58 To: boost@lists.boost.org Subject: Re: [boost] Why does boost::thread::thread_start_function havecatch(...)? (Win32)
"James Talbut" <James.Talbut@omg3d.com> writes:
By calling std::terminate in the catch handler we lose the JIT debugger - and thus information about what the exception is that we haven't caught. Without the catch the process is still going to be killed, so what's the benefit of having that?
It's not specified in either the pthreads docs or the Windows docs what happens if the thread function leaks an exception, since these are C APIs. Depending on the compiler/platform a leaked exception in a thread may either just terminate the thread, may terminate the whole process, or may cause undefined behaviour. I know that some platforms don't support exceptions in C stack frames, and will throw a wobbly.
By catching the exception and calling terminate(), the thread library makes it explicit that this is an error.
Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________