From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-14 09:33:15
From: "Hillel Y. Sims" <hsims_at_[hidden]>
> "William E. Kempf" <williamkempf_at_[hidden]> wrote in message
> > This means terminate_thread()
> > instead, which only terminates the current thread and not the
> > A set_terminate_thread_handler() can be employed to handle this case in
> > same manner that you'd use for application termination.
> Hi Bill, what do you think of the following code?
I'm not sure what you're trying to say. If it's that not properly handling
exceptions can lead to inconsistent state (true even of single threaded
apps), and in a multi-threaded app this means the potential for dead lock
and other such synchronization errors (on top of simple data invariant
issues), then yes, I've stated that over and over again in this thread. The
argument is that such code is faulty to begin with, and undefined behavior
is what should be expected. But so long as the programmer deals with
exception safety properly, then propogating the exception can be useful in
many cases, and is likely to be the only solution that will allow the
possibility for a graceful exit from the application in many others. Far
from perfect, and I think both sides of this have very valid arguments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk