Ted Baker wrote:
Yes; that's been considered in the past discussions. Along with many other alternatives. (The same had been proposed for DCE/C exceptions reporting SIGSEGV and other "hardware" failures.) Generally, most people end up thinking that's a little too syntactically asymmetric; there are uses of catch(...) that really do need to isolate a subsystem by catching everything, and breaking that model seems extreme. But it's also true that might be the lesser of two evils, since it should be uncommon. And so the argument sways back and forth, thus far without authoritative resolution. I've been debating some of these exact issues with various people since threading became common enough that C++ people wanted to use it, armed with their newly defined exception model that actually worked on some of the common implementations of C++. (Yeah, that long ago.)... the problem isn't with the model, but rather with the effect of that model on existing code that all-too-casually and agressively eats exceptions it doesn't understand. I think there are vanishingly few circumstances where a blind catch(...) without an unconditional re-throw should be considered "legitimate". If you don't completely understand what an exception means, you cannot claim to have completely recovered, and therefore cannot reasonably finalize propagation. (And when you catch anonymously, you can't possibly understand what they mean since you can't even identify them.) On the other hand, regardless of whether the semantics are meaningful or reasonable, the syntax is legal and apparently (unfortunately) in common use, so I can't dispute that you need to consider that.This problem could be eliminated by specifying that cancellation is a special case, that cannot be caught by catch(...), i.e., that it can only be caught by a handler that names it explicitly, or that it cannot be caught at all.
The problem, of course, is that everyone and nobody is "right" -- and it's hard to converge on one middle ground without someone suddenly realizing, "but then THAT wouldn't work". And then again, since the C++ standard committee was never even peripherally involved before, everyone knew that it was little more than idle speculation.
-- /--------------------[ David.Butenhof@xxxxxx ]--------------------\ | Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect | | My book: http://www.awl.com/cseng/titles/0-201-63392-2/ | \----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/