David Abrahams wrote:
Um, well, in a way I guess that is what I'm saying, though I was coming from a different angle and going someplace difference. I was really just casually commenting that, in general, a policy of grabbing all passing exceptions and smashing them indiscriminately into the ground didn't seem like a particular healthy strategy.Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx> writes:David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> writes: | Dave Butenhof <David.Butenhof@xxxxxx> writes:| | >>The problems with catch(...) eating all exceptions are maybe not as| >>bad as you think. As a matter of fact, there are vanishingly few | >>exceptions that demand special recovery actions that wouldn't work for | >>all other exceptions. Systems designed that way tend towards | >>fragility. | >> | > I see an immense difference between a pragmatic statement that "in | > practice there seem to be few exceptions" and something on which | > cross-platform, mixed-language, modular environment programmers can | > depend as a law. C++ does not say that "all exceptions can be | > finalized and recovered fully by performing these steps". To presume | > they can is fragile.| | It also doesn't say "no destructors will throw exceptions", but we| generally rely on them not to, because it makes programs hard to | write. There are a whole host of things we leave up to good | programming practice, most of which don't have to do with EH. Agreed, but we can't specify things like that. If we assume some working hypothesis to hold, then we have to make that assumption clear in the specification. I think that is the point Dave Butenhof wasmaking.I didn't think so, at all. I hope Dave will clarify on his own, though, especially if I'm wrong.
If the standard doesn't say that "all exceptions can be silently finalized without any special action", then I think any program that tries to do this with arbitrary exceptions is asking for trouble. It's not reliable, it's not portable, it's arguably not "correct".
You offer the counter-argument that the same can also be said for code that raises an exception that requires special action -- except, one must allow, where it can also be sure that it will control finalization.
But the standard, apparently, neither supports nor refutes either view. Which is very likely as it should be, since the standard applies to all sorts of special circumstances where trying to describe this sort of business just gets confusing and doesn't really help anyway.
The real issue isn't so much catching without a re-throw, but catching and dropping arbitrary exceptions. If you don't claim to know how to finalize a bad_alloc error, what business do you have catching it? (And since catch(...) is anonymous, even if you could handle it you can't identify it.) I'm not convinced there's any rational excuse for finalizing bad_alloc unless you know how to free up some memory to "cure" the problem that caused it. (Nor would there be any particular benefit.) If you can't deal with it, you need to let it propagate to someone who can; or to terminate the process.AFAICT the discussion is about whether it makes sense to support programs which do catch(...) without rethrowing, and if so, how. Right now we're discussing a morality issue: "is it inherently evil to catch(...) without rethrowing?" My point is that one could just as well (and perhaps more justifiably) claim that it's evil to throw any exception that can't be dealt with via a catch(...) block that doesn't rethrow, where that block was designed to handle, say, bad_alloc.**
In the case of cancel, it's possible (though not "inarguably correct") to define the exception's destructor to re-cancel. There's no good analogy for bad_alloc, though; you can't just free arbitrary objects and presume the application can continue. But, sure, this could be argued back and forth forever, and it's not strictly relevant to the "charter" of this group...
Certainly true, at least to the extent that if the exception doesn't represent a "program state", it may not matter; and if it does, then at least in many cases the situation will be self correcting. (That is, when you drop bad_alloc on the floor, either the situation has been corrected -- whether deliberately or simply by unwinding some set of frames with local objects -- or else it'll reassert itself soon enough.)(**) this isn't really about the exception objects, but about the conditions of program state they represent.
There seems to be some disagreement over where cancel fits in this spectrum. It is a sort of program state (actually, thread state), and can't simply be thrown away (in normal applications) without breaking program semantics. On the other hand, it's a "one shot" that won't be automagically reasserted. Jason's model resolves this by making it artificially self-reasserting, via the exception object's destructor. Alexander argues against this. I think I'd be happy with an automatic re-cancel on a catch(...), but ideally I'd also like someone to be able to catch(cancel) without needing to do something extra (even a 'cancel.finalize()') to prevent re-cancellation. Given widespread use of catch(...), though, I'm willing to accept that "re-cancel on destruct" might be the least objectionable compromise.
-- /--------------------[ 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 ]---/