Exceptions
in [C++]
|
Next: C++/CLI limitations?
From: David Abrahams on 8 Jul 2005 06:20 alfps(a)start.no (Alf P. Steinbach) writes: > If showing that a statement is incorrect, by quoting the parts it > refers to, is ridicule, then I ridiculed your statement. It was not my statement in the first place. > However, quoting is normally not considered ridicule. It wasn't your use of quotation that smelled like ridicule to me. It was "I didn't think of that. It's, uh..." > You're off-topic both regarding Peter's alleged intellectual > capacity I drew no conclusions about Peter's intellectual capacity nor did I make claims about your view of said capacity. What I wrote was that quoting Peter out of context makes his quoted statement seem simpleminded. > and my alleged choice of rhetorical tools. Well I'm willing to consider that I might be off base, but I don't think I was off-topic. Anyway, if you tell me you meant something else by all that, I'm willing to forget it. What about the rest of my post? -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 8 Jul 2005 09:23 In article <uslyqqppk.fsf(a)boost-consulting.com>, David Abrahams <dave(a)boost-consulting.com> writes >You seem to assume that aborting is the only alternative to unwinding >when a violated invariant is detected. In an interactive application >like a word processor it's usually possible to recover the state of >the document and offer the user an opportunity to save when a violated >invariant is detected. All of that can be done without any >unwinding. Indeed and the point that seems to be being missed is that the options aren't abort or throw. Another viable option is to call an error handling function, which can, for example, do essential clean-up before aborting or throwing. > -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 8 Jul 2005 11:03 * Francis Glassborow: > * David Abrahams: > > You seem to assume that aborting is the only alternative to unwinding > > when a violated invariant is detected. In an interactive application > > like a word processor it's usually possible to recover the state of > > the document and offer the user an opportunity to save when a violated > > invariant is detected. All of that can be done without any > > unwinding. > > Indeed and the point that seems to be being missed is that the options > aren't abort or throw. Another viable option is to call an error > handling function, which can, for example, do essential clean-up before > aborting or throwing. To do that open documents (say) must be available to the clean-up code, and that means globally accessible structures or registering clean-up actions with some singleton. Both suffer from the same problems wrt. to possible broken global state as unwinding does. And they add code that is more error-prone because, first, it's more code, and second, because it's invasive code, and third, because there's no (under assumption of valid higher level states) guarantee of execution, as there is with RAII. And, it's reasonable and common (it even has built-in language support) to do recursive clean-up when an object is destroyed. But ensuring destruction of objects can be difficult when the stack is not unwound. So with no stack unwinding the objects may have to be designed to be able to do total clean-up without being destroyed, which effectively means adding zombie states. Summing up: avoiding stack unwinding while insisting on clean-up means globals, invasive support code, probably zombie states, and probably more that I didn't think of right here, and it's got the same problems wrt. broken invariants at higher levels as stack unwinding does. Nothing seems to be _gained_ by that centralized approach. And much seems to be lost. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 8 Jul 2005 21:38 alfps(a)start.no (Alf P. Steinbach) writes: > * Francis Glassborow: >> * David Abrahams: >> > You seem to assume that aborting is the only alternative to unwinding >> > when a violated invariant is detected. In an interactive application >> > like a word processor it's usually possible to recover the state of >> > the document and offer the user an opportunity to save when a violated >> > invariant is detected. All of that can be done without any >> > unwinding. >> >> Indeed and the point that seems to be being missed is that the options >> aren't abort or throw. Another viable option is to call an error >> handling function, which can, for example, do essential clean-up before >> aborting or throwing. > > To do that open documents (say) must be available to the clean-up code, > and that means globally accessible structures or registering clean-up > actions with some singleton. Guess what? You already did that, because your interactive document editor supports undo (doesn't it?) When I wrote desktop document editing software, upon the detection of a fatal error it was trivial to ask the undo mechanism to restore any document state that was currently being modified and give the user an opportunity to save the open documents (under new names, of course). > Both suffer from the same problems wrt. to possible broken global > state as unwinding does. The problems aren't quite the same, because unwinding touches global state that doesn't need to be touched, while the other strategies go directly to the state that needs to be worked on and leaves everything else alone. > And they add code that is more error-prone > because, first, it's more code, Nope; you had to write it anyway. > and second, because it's invasive code, Did I mention that you had to write it anyway? ;-) > and third, because there's no (under assumption of valid higher > level states) guarantee of execution, as there is with RAII. Not sure what you had in mind here. > And, it's reasonable and common (it even has built-in language support) > to do recursive clean-up when an object is destroyed. What does an object being destroyed have to do with anything? > But ensuring destruction of objects can be difficult when the stack > is not unwound. So with no stack unwinding the objects may have to > be designed to be able to do total clean-up without being destroyed, > which effectively means adding zombie states. No, you're going to stop the program anyway, which means the objects die automatically. > Summing up: avoiding stack unwinding while insisting on clean-up > means globals, invasive support code, probably zombie states, and > probably more that I didn't think of right here, Have you ever tried to do it, or are you just speculating? Because it worked for me, and I didn't experience any problems with it. > and it's got the same problems wrt. broken invariants at higher > levels as stack unwinding does. Nothing seems to be _gained_ by > that centralized approach. Centralized? -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: kanze on 8 Jul 2005 21:37
Alf P. Steinbach wrote: > * Francis Glassborow: > > * David Abrahams: > > > You seem to assume that aborting is the only alternative > > > to unwinding when a violated invariant is detected. In an > > > interactive application like a word processor it's usually > > > possible to recover the state of the document and offer > > > the user an opportunity to save when a violated invariant > > > is detected. All of that can be done without any > > > unwinding. > > Indeed and the point that seems to be being missed is that > > the options aren't abort or throw. Another viable option is > > to call an error handling function, which can, for example, > > do essential clean-up before aborting or throwing. > To do that open documents (say) must be available to the > clean-up code, and that means globally accessible structures > or registering clean-up actions with some singleton. Both > suffer from the same problems wrt. to possible broken global > state as unwinding does. And they add code that is more > error-prone because, first, it's more code, and second, > because it's invasive code, and third, because there's no > (under assumption of valid higher level states) guarantee of > execution, as there is with RAII. The difference is that in this case, you are doing a targeted set of clean-up actions. You know exactly what you are trying to do, and can evaluate the risk. When you throw, you don't really know what objects might be on the stack between you and where ever the exception is caught. This makes evaluating the risk a lot more difficult. And of course, if necessary, calling specialized code means that the code you actually call can take the uncertainty of the global state into consideration. As a simple example, I have a class which represents temporary files -- it contains the name of the file (in an std::string), and calls remove in its destructor, using the name it has, with no further checks. In an emergency clean-up action, however, I would doubtlessly add a few coherency checks -- that the name is in the directory (or a directory) where I normally create temporary files, for example. So that if the name has been corrupted, I won't accidentally destroy something critical. -- James Kanze GABI Software Conseils en informatique orientýe objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sýmard, 78210 St.-Cyr-l'ýcole, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |