boost.threads [was RE: [boost] Re: sockets /network programming Requirements]

From: williamkempf_at_[hidden]
Date: 2001-08-03 13:57:48

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > A good attempt at bypassing the problem, but it doesn't cover all 
the
> > basis.  This *ISN'T* really an exception but instead is an 
attempt at
> > program flow control.
> 
> sorry, it is the same (ISO/IEC 14882:1998(E) pg 291):
> 
> "Exception handling provides a way of transferring control
>  and information from a point in the execution of a program to
>  an exception handler associated with a point previously passed
>  by the execution."

Exceptions do provide flow of control semantics, yes.  But for the 
explicit use of handling "errors".

> > The problem is that code can still catch these
> > exceptions, even if you insure they are rethrown.  Imagine, for
> > example, a catch block coded as:
> >
> > try
> > {
> > }
> > catch(...)
> > {
> >    LogError();
> >    exit();
> > }
> >
> > The programmer probably doesn't want LogError() called for this 
non-
> > error, and he definately doesn't want the program to exit.
> 
> 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.

Bill Kempf