|
Boost : |
From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-03 13:07:22
> 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."
> 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.
regards,
alexander.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk