Boost logo

Boost :

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
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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at