From: williamkempf_at_[hidden]
Date: 2001-08-03 14:52:09
--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> > but then his code would never call thread::exit so there
> > will be no problems. also, IMHO catch(...) without "throw;"
> > or program termination is inherently flawed (e.g. who is
> > supposed to delete the object thrown by not so smart pointer,
> > etc) so i do not see any good reasons not to provide
> > exception based thread::exit even w/o catch(...)
> > workarounds.
>
> Did you totally miss the point about LogError()? *ANY* processing
> done within the catch(...) block is probably not wanted when the
> exception is of type boost_thread_exit_dont_catch_me(). Using
> exceptions is only going to lead to what is viewed as bugs, and
bugs
> that can't be worked around. I won't use such a system, and I'll
bet
> most others won't as well.
In case I've not convinced you yet, here are two other core language
issues with this approach.
1) If while processing an exception a local is destroyed whose
destructor throws an exception, terminate will be called. (15.2/3)
2) Consider the following: void foo() throw() { bar(); }.
What's needed is exception style stack unwinding with no possiblity
of the user circumventing things. To truly get this in a portable
manner that covers all the bases is likely going to require a core
language change and compiler support. This is precisely one of the
reasons why we need a "designed from the ground up" C++ solution
instead of a simple wrapper around POSIX or Win32 threads. We're
doing the best we can to give a library implementation of such a
design, which hopefully can be used for some today, noting any holes
that exist because of changes needed to the C++ abstract machine. If
a concept (like this one) can't be done in the library, we're
removing it with the hopes that it can be added again if/when it's
adopted into the language standard.
Bill Kempf