Exceptions
in [C++]
|
Next: C++/CLI limitations?
From: David Abrahams on 16 Jul 2005 06:22 alfps(a)start.no (Alf P. Steinbach) writes: > * David Abrahams: >> >> A precondition violation is -- by definition -- unrecoverable. >> http://en.wikipedia.org/wiki/Precondition >> >> If you want to use some other definition where it's a fuzzier notion, >> be my guest, but then we are going to be talking at cross-purposes. I >> also warn you that the term "precondition" loses almost all of its >> power when you do that. > > Sorry, but that's incorrect. Only if you insist on complicating the way it's interpreted. > As a simple counter-example, write a Basic interpreter in C++, then > when a precondition fails in the executing Basic interpreter, > recover at the C++ level -- the C++ program can happily continue > executing. Well, duh! Write a C++ program. If a precondition fails when executing the program, recover at the OS level -- the OS can happily continue executing. Of course I meant "unrecoverable for the program whose precondition is violated." > Note that the existence of this _one_ counter-example invalidates > your notion of absolute unrecoverability. Oh, totally, I agree. Unless you take the "obvious" interpretation of what I said. > As a more extreme example, you can turn off that computer, reboot, > and restore all state from some restore point. > > You might and probably will argue that that's not recovery within the > "program". You catch on fast. > And that's correct as far as it goes That's as far as it was meant to go. > but that argument is precisely the direction one might need to > direct one's attention to understand this. Can you recover without > rebooting the physical computer? Then you're within the OS > "program" (and nowadays some folks prefer to run everything in a > virtual OS just to be able to do this, it's not academic). Can you > recover with some even less extreme measure? Then you might well be > within an ordinary C++ simple application program. You just made a leap from recovering at a meta-level to recovering at the same level. An "ordinary C++ simple application program" has no clear isolation between its various parts, so it usually isn't possible to make a well-founded decision that the brokenness stops somewhere before the process boundary when a precondition is violated. You can guesstimate, but then you're in the territory of wishful thinking, not in that of being able to reliably claim that the program is functioning normally. The OP needs to be able to keep the program functioning normally in the face of database corruption, which means staying out of the territory of wishful thinking. > Can you recover without sacrificing a thread or two? Then you're > even within the C++ standard's limited notion of program, and one > example was given above. It's all about abstraction levels. > Generalizing from a limited context and level up to "everything", as > you did, is not valid. My statement that was delivered in a limited context, and I did *not* generalize it up to "everything." AFAICT you did that and then criticized me for the consequences of it. -- 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: Bob Bell on 16 Jul 2005 06:23 Alf P. Steinbach wrote: > * David Abrahams: > > > > A precondition violation is -- by definition -- unrecoverable. > > http://en.wikipedia.org/wiki/Precondition > > > > If you want to use some other definition where it's a fuzzier notion, > > be my guest, but then we are going to be talking at cross-purposes. I > > also warn you that the term "precondition" loses almost all of its > > power when you do that. > > Sorry, but that's incorrect. > > As a simple counter-example, write a Basic interpreter in C++, then when a > precondition fails in the executing Basic interpreter, recover at the C++ > level -- the C++ program can happily continue executing. If anything, that's an example of a "fuzzier notion." Bob [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 16 Jul 2005 19:48 Gerhard Menzl wrote: > Dave Harris wrote: >>I think your real problem there is that you have tons of >>unsaved work. You can cope with program bugs, maybe, but you >>probably can't cope with O/S crashes or power cuts so you need >>a more general strategy. >>My employers write word processors. Our approach is to write >>the document to a temporary file every 10 or so minutes. We >>delete it during a normal shutdown and also after a successful >>user-save. Any documents found during start-up are then >>unsaved work lost due to a crash, and we ask the user if she >>wants them restored. >>This mitigates the problem. They never lose more than 10 >>minutes work. That's acceptable because crashes should be >>rare (if they are a daily occurance we are already in big >>trouble). We are confident we can restore the document because >>we had a known sane state when it was written out. > Automated saving is certainly a good idea, but it does not really > address my point, for which I merely used the word processor as an > example. You can do a lot of typing, drawing, or whatever in ten > minutes. Destroying that work without at least attempting to save it > upon a failed assertion is not going to enhance your reputation as a > software vendor. I think that part of Dave's point is that failed assertions, in general, aren't going to enhance your reputation as a software vendor. So they should be rare enough that the lost ten minutes doesn't matter. Of course, if the software is to run on a modern machine, you can do the save every 30 seconds, or even more often, if it will matter. Note to that saving the work is also valid for system crashes. And in the code I write (and judging from yours and Dave's contributions here, probably in your code as well), system crashes are a lot more frequent than assertion failures in my code. -- James Kanze mailto: james.kanze(a)free.fr Conseils en informatique orientýe objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre 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! ]
From: Dave Harris on 17 Jul 2005 16:26 gerhard.menzl(a)hotmail.com (Gerhard Menzl) wrote (abridged): > Automated saving is certainly a good idea, but it does not really > address my point, for which I merely used the word processor as an > example. You can do a lot of typing, drawing, or whatever in ten > minutes. Well, you can do about 10 minutes worth. For something like a word processor it will take at most 10 minutes to recreate the lost work. The point is the loss is bounded. Where-as if you continue running after the program state has become invalid, you risk corrupting everything. The loss is not bounded. So the principle applies even when the app is doing something like, eg, telemetry of Mars rover missions, where the data may be highly valuable and impossible to recreate. -- Dave Harris, Nottingham, UK. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gerhard Menzl on 3 Aug 2005 11:27
David Abrahams wrote: > Who said anything about recovery? Er, you did. Several times. That's how the Undo example came up. > I am talking about stopping execution at the earliest possible moment > when an invariant violation is detected. And I questioned whether stopping execution upon detection of an invariant or precondition violation is always the correct thing to do. >>Otherwise, how would you obtain the necessary context that is >>normally not accessible in a global, low-level function like an >>assertion handler? > > I don't understand the question. You: stack unwinding is a no-no I: so you abort and lose all unsaved work You: no, you let a separate clean-up function do the saving I: then you need a separate mechanism (which may exist already if you have an Undo feature), otherwise how would the clean-up function, which cannot possibly know anything about the application state, do its work, right? >>You argued (elsewhere) that the Undo feature in a word processor >>provides such a mechanism (or a substantial building block of one) >>anyway. Well, what about applications that don't have an Undo feature? > > I guess you'd better write one ;-) Now it's my turn not to understand. There are applications where Undo is part of the specification, and applications where it isn't. Because there are operations that cannot be undone, for example. You can abort a phone call, but you cannot undo it (although people have been known to badly wish for such a feature). > Imagine you wrote a word processor without Undo. You wouldn't really > expect stack unwinding to automatically undo any edits in progress > would you? Not unless input handling were implemented recursively. *g* > A precondition violation is -- by definition -- unrecoverable. > http://en.wikipedia.org/wiki/Precondition That definition doesn't say anything about recovery. It says: "In computer programming, a precondition is a fact that must always be true just prior to the execution of some section of code. [...] If a precondition is violated, the effect of the section of code becomes undefined and thus may or may not carry out its intended work." Whether the malfunction of a "section of code" doesn't matter or requires stopping all execution or anything in between depends on what the code does and the importance it has in the overall scheme. > If you want to use some other definition where it's a fuzzier notion, > be my guest, but then we are going to be talking at cross-purposes. I > also warn you that the term "precondition" loses almost all of its > power when you do that. I am always eager to unfuzzy my software engineering notions, otherwise I wouldn't take part in this group. But the definition you cited simply doesn't say anything about how the rest of the program is affected when one part cannot fulfill its responsibility. >>>In your application, calling database table integrity a precondition >>>is only going to confuse things and make your code more complicated. >>>Once you understand that database integrity is not a precondition, it >>>becomes very clear that you need to check for corruption in certain >>>places and make sure that you do something sensible if you detect it. >> >>I think it depends on whether you regard the database as an integral >>part of your system or something external. > > No. If your program is expected to be resilient against condition ~X, > then X is not a precondition. Do yourself a favor and use the clear > and accepted terminology. Your programs will benefit. Suppose you write several distinct values into a database table. Your program logic is supposed to make sure that the same value is never used twice, and the database definition ensures that the database engine applies a second check (by using a unique key, for example). If a function that operates on the data relies on the values still being unique after retrieval, that uniqueness is, by your (Wikipedia) definition, a precondition. Yet you say it's not. Why? Because you always have to check data retrieved from a database for possible corruption? I don't think this is always feasible. What am I missing? -- Gerhard Menzl #dogma int main () Humans may reply by replacing the thermal post part of my e-mail address with "kapsch" and the top level domain part with "net". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |