Re: [boost] [Boost.Thread]: consider removing catch(...) from thread_proxy

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-01 11:39:21

David Abrahams writes:

>Roland Schwarz writes:
>
>  
>
>>But please don't get me wrong. I am not advocating to remove the
>>catch all. 
>>    
>>
>
>I am.
>
>  
>
As I already posted in a previous mail: I also do not have objections 
against removing
it. We both seemingly changed our minds to follow the arguments of the 
original
poster.
But you think it  will have a big impact, and I do not know for sure.
I would have suggested to roll out a small test  for the currently 
supported compilers,
to see how big the impact would be to regressions.
But as you say:  "With most of the compilers I use an uncaught exception 
thrown from
a user thread will terminate the application", we can skip this step and 
assume it for given.

>>Also I cannot understand how a C++ compiler should be able
>>to detect that a thread has ended and call the respective
>>process shutdown if there are any uncaught exceptions.
>>    
>>
>
>It's known as "compiler magic."
>
>  
>
Hmm, hmm, I am definitely not educated enough in this discipline ;-)

>Urr, abort(), terminate(), and exit() all come about as close as you
>could want to addressing process termination.
>  
>
Yes, this is most likely the case. And if you mean that this should 
happen from the users
program, I am with you. On the other hand the standard has nothing to 
say what
this will cause when called from a thread.
No wait:
Calling the function void exit(int); terminates the program without 
leaving the
current block <...> If exit is called to end a program during the 
destruction of an
object with static storage duration, the program has undefined behaviour.

So when calling this function (e.g. as a result to an exception) during 
the main
thread is ending the program and inside a global destructor the program
has undefined behaviour.

I don't know if this is any different than the current situation.

>And having any catch all clause at all will prevent us from reaching
>other goals desired by the instigators of this thread.
>
>  
>
Another possible approach would be to do differently in a debug build, since
the only goal the original poster seems to aim is to get meaningful 
debug information.
I am tempted to compare this to stack probes, no mans land guards for 
malloc (sorry
new) and the like, which are also normally only used during debug 
builds. These features
all have the potential to cause error slip through in release builds.

But of course it would be good to know that regressions also run with the
catch clause removed. Or do you expect much fails? This would be quite
contrary to the claim that 100% of the C++ programmers are expecting
an uncaught  thread exception to tear down the process.

Do you think it would be possible to just try this out?
I mean to schedule an extra regression cycle with the catch all removed
and see how much of the code is affected?

>>What about adding a dedicated process tear down function to the
>>library?  This function could be called by the user if needed.
>>    
>>
>
>What's wrong with what the standard provides?
>
>  
>
Nothing besides not addressing threading.

Regards,
Roland