Matt Hurd <matt.hurd@gmail.com> writes:
On 25/08/05, John Maddock <john@johnmaddock.co.uk> 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 specifications.
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 www.boost-consulting.com