Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-26 08:17:41

Matt Hurd <matt.hurd_at_[hidden]> writes:

>>On 25/08/05, John Maddock <john_at_[hidden]> wrote:
> <snip>
>> I think I'd come down on the other side: this isn't a minor change, it's a
>> complete change of semantics and we should be very careful about such a
>> change. With most of the compilers I use an uncaught exception thrown from
>> a user thread will terminate the application, which may be what you want, or
>> it may not: but it sure is drastic! You can always trap uncaught exceptions
>> yourself and call abort (or whatever) if that's what you want. The debugger
>> I use will also let you trap all thrown exceptions if that's what you want,
>> whether they all do that I don't know.
>> Also 2c worth,
> After thinking about it some more, I'd still much rather see a
> screaming application halt than the false sense of security suggested
> by silent failure.

If that's what you want, you ought to force it to halt. Probably the
most reliable way is to put an empty exception-specification on the
function and make sure it's being called by another C++ function, just
for good measure. Of course, you'd need to take special measures for
MSVC, which doesn't implement any runtime behavior for exception

> Yes, it is a big change, and needs more comment.
> As you suggest, you may catch anything in your own handler. I worry
> that silent collection of exceptions will allow too many subtle errors
> to slip through, especially in the land of concurrency. It has
> happenned to me that I've let errors slip through in pooled workers
> where I didn't notice rare failures and the loss of a single worker
> thread. A screaming halt would have woken me up from my lazy
> stupidity...

Another possibility (a good one IMO) would be to allow a
user-replaceable handler there, which could abort, log a message and
then abort, eat the exception, etc., as desired. If the default is to
eat the exception, you have perfect backward compatibility.

Dave Abrahams
Boost Consulting

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