Boost logo

Boost :

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-08-08 07:55:02


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

/ikh


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk