Re: [boost] [thread] catch(...) removed

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-09-25 22:45:37

Kim Barrett wrote:
> [checking cvs] Ah, yes. So you've maintained the old behavior of always
> calling on_thread_exit() on the way out of thread_proxy(). The email from
> Roland that I quoted raises the question of whether that's actually needed
> or even correct, but that's a different issue from the elimination of the
> annoying catch-all.

Unfortunately I was held off for some time by other tasks, so I did not
see this thread earlier.

Explanation of the double call:

In case the automatic cleanup works the call in the proxy is not really 
necessary. The cleanup in this case even is called when threads are used
that have not been started by as boost:threads i.e. native threads.

But this is compiler dependent, and might break when new versions pop 
up, or e.g on borland. In this case the on_thread_exit call becomes
mandatory. I.e. tss still behaves correctly for threads that have been
launched via the boost::thread API.

So on the one hand I would like to see the original behaviour restored.
I agree on the other hand, that it is not very sensible having threads
with uncaught exceptions dying silently.

But putting it into a guard however is not an ideal solution since it
requires, that on_thread_exit must not throw, which is a severe 
restriction, because on_thread exit is responsible to run the atexit 
handlers which might even call user provided code. And this might make
it harder to find the original source of error if they throw.

So, which other solutions are possible:
1) omit the on_thread_exit in case of uncaught exceptions.
    (and do away with the try clause)
2) rethrow ?
3) emit a debugging message (at least this is why I would want the
    catch(...) removed)
4) Forcibly shut down the entire process

While 1) leaves the issue to the crt library I am not sure if this
will give rise to implementation dependent behavior. At least the
standard says that terminate must be called when an exception handler
cannot be found. This undoubtedly is the case, but on the other hand
the standard currently isn't about threads at all. But I think one can
reasonably expect that the crt vendor took care of this case.

Clause 2) is almost the same than 1) but the on_exit_thread executed.
Whether this is a good thing depends. I am inclined to not.

Putting a debug message as in 3) only creates overhead. At least the
crt already can be expected to take care in a sensible way.

And 4) most likely will render the debugger less effective.

So my opt. is for 1).

Roland