Exceptions
in [C++]
|
Next: C++/CLI limitations?
From: Niklas Matthies on 10 Aug 2005 17:11 On 2005-08-10 18:37, Gerhard Menzl wrote: : > Why should throwing an exception immediately after testing the > precondition be "part of the function's undefined behavior"? This > would only be true if the stack is corrupted, but that's not what > the precondition is about. Or would you argue that any precondition > violation may be due to stack corruption? Moreover, any precondition fulfillment may be due to stack corruption. So the only safe thing to do after detecting it is to terminate the program. -- Niklas Matthies [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dave Harris on 14 Aug 2005 14:49 gerhard.menzl(a)hotmail.com (Gerhard Menzl) wrote (abridged): > But is it? When you specify a precondition for a function, you need a > clear idea of what the consequences of a violation are, which part of > what the function does is affected, and which part isn't. You don't need a clear idea, and sometimes no part of the function is affected at all. For example: int get_count( int *p ) { assert( p != 0 ); return 0; } is reasonable. One reason for writing such is to reserve a condition for /future/ implementations to exploit, if they want to. Another reason is to verify something that you think ought to be true, even if you don't have any plan to exploit that truth. > By the way, how does Eiffel, in the context of which the terms > precondition and contract originated, after all, handle this? In Eiffel, pre-condition checking is done by the language and can be turned off as an optimisation, so callers must not rely on it. If you want to recover from a condition failure, you should write your own code to check it, not rely on language-level assertions. -- 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 17 Aug 2005 08:42 Dave Harris wrote: >>But is it? When you specify a precondition for a function, you need a >>clear idea of what the consequences of a violation are, which part of >>what the function does is affected, and which part isn't. > > You don't need a clear idea, and sometimes no part of the function is > affected at all. For example: > > int get_count( int *p ) { > assert( p != 0 ); > return 0; > } > > is reasonable. As the author of get_count(), I can tell that at present a violation of the precondition will have no consequences, and that undefined behaviour will be invoked as soon as the function is changed to dereference p. That's what I call a clear idea. > In Eiffel, pre-condition checking is done by the language and can be > turned off as an optimisation, so callers must not rely on it. If you > want to recover from a condition failure, you should write your own > code to check it, not rely on language-level assertions. How does the Eiffel runtime handle violated preconditions? Display a diagnostic message and abort? -- 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! ]
From: Gerhard Menzl on 22 Aug 2005 06:06 David Abrahams wrote: > No, it ceases to be a precondition the moment that the author of the > function *documents* the throwing of that exception as the function's > response to the condition being violated. > > (**) It's inconsistent to say, "This function has X as a precondition. > However, if X is violated, I promise you it will throw an exception > and do nothing else." The correct thing to do if you are going to > make that promise is drop the first sentence. Originally, I took you to mean that throwing an exception upon detecting a violated precondition is always wrong. Now you seem to say that *documenting* such an exception is inconsistent with the specification of a precondition. These are two very different statements. The first is about implementation, the second about interface. Or, to put it polemically: what's wrong with throwing a ViolatedPreconditionException, as long as I don't document it? By the way, the term "precondition" seems to be used in meanings that differ from the one you have sketched. In the Eiffel world (as far as I can tell), a precondition is something that the caller must guarantee before invoking a function. This would rule out stack integrity or other global conditions which the caller cannot guarantee. Another conflicting use I have found is from P. J. Plauger's Editor's Forum in the June issue of C/C++ Users Journal where he writes about a new C library called "Safer C": "But any implementation of the function must test that its arguments meet all preconditions. The runtime equivalent of a diagnostic is to call the diagnostic handler. If the handler returns, the function then cauterizes any output buffers and returns an error code." -- 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! ]
From: David Abrahams on 22 Aug 2005 10:48
Gerhard Menzl <gerhard.menzl(a)hotmail.com> writes: > David Abrahams wrote: > >> No, it ceases to be a precondition the moment that the author of the >> function *documents* the throwing of that exception as the function's >> response to the condition being violated. >> >> (**) It's inconsistent to say, "This function has X as a precondition. >> However, if X is violated, I promise you it will throw an exception >> and do nothing else." The correct thing to do if you are going to >> make that promise is drop the first sentence. > > Originally, I took you to mean that throwing an exception upon detecting > a violated precondition is always wrong. No. It's almost always wrong, but that's a different issue. > Now you seem to say that *documenting* such an exception is > inconsistent with the specification of a precondition. That's correct. > These are two very different statements. Of course. I know what I'm saying. > The first is about implementation, the second about interface. Or, > to put it polemically: what's wrong with throwing a > ViolatedPreconditionException, as long as I don't document it? Well, I've been through the arguments about why it's usually a bad idea in this thread. You can just review my postings (and not only the ones in reply to yours). > By the way, the term "precondition" seems to be used in meanings that > differ from the one you have sketched. In the Eiffel world (as far as I > can tell), a precondition is something that the caller must guarantee > before invoking a function. In my definition the caller must guarantee the precondition also, since the alternative is undefined behavior. I don't know what I've said that could make you think otherwise. > This would rule out stack integrity or other global conditions which > the caller cannot guarantee. If the caller is invoking the callee other than as some expression of undefined behavior, it can. I'm assuming that even in Eiffel, the moment stack integrity is violated you have undefined behavior. Once you enter undefined behavior land, all bets are off and all actions are part of that undefined behavior. Undefined behavior means "all bets are off" and no guarantees (not even the ones you /think/ the caller can ensure) are really valid. > Another conflicting use I have found is from P. J. Plauger's Editor's > Forum in the June issue of C/C++ Users Journal where he writes about a > new C library called "Safer C": "But any implementation of the function > must test that its arguments meet all preconditions. The runtime > equivalent of a diagnostic is to call the diagnostic handler. If the > handler returns, the function then cauterizes any output buffers and > returns an error code." I'm not sure that's a conflict either. -- 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! ] |