Re: [boost] Re: Re: Threads & Exceptions

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-08 08:57:13

From: "Iain K.Hanson" <iain.hanson_at_[hidden]>

> > William E. Kempf
> >Sent: 07 August 2002 19:22
>
>
> >That's back to the argument of passing exceptions, and the argument
against
> >is that it's very possible the polling function(s) to detect this will
> never
> >be called.  Propogating the exception out by default leaves the user
with a
> >false sense of security, while a call to terminate() forces the user to
> >address the issue and pick the solution appropriate for the use case.
>
>
> O.K. I didn't have any strong view on this at first. But the more I think
> about this, the more I'm comming down on the side of exception passing.
If
> it was only my own code that was to run on the thread then I would not
have
> a problem with terminate being called. It would be my fault and the
solution
> would be in my own hands. But it could be third party code
> from a library that is running on the thread. And I don't want that
thread
> to bring my system down unless I chose to let it. My business critical
app
> can always re-start the thread and will test what the exception is only
if
> it cares ( probably for logging so as to report a bug).
>
> Alternatively, if the behaviour could be configurable with the default
being
> terminate that would also be fine.

It already is, isn't it?

To protect yourself from 3rd-party termination, you can just add an
exception-handling wrapper which eats the exception and exits normally.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com