Boost logo

Boost :

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

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