Re: Exceptions, Go to Hell!
Joshua Maurice <joshuamaurice@gmail.com> wrote:
On Sep 8, 6:09?am, "Daniel T." <danie...@earthlink.net> wrote:
"joe" <jc1...@att.net> wrote:
Daniel T. wrote:
... The question was "what do you call those things that return
codes and C++ exceptions are used for?" My answer is, "precondition
violations."
Oh? Just that? What about postconditions and invariants?
When a library writer finds that a postcondition or invariant failure
has occurred in his code, it should be fixed. When a precondition
failure occurs in his code, he should throw an exception, there is no
way for him to "fix" it.
From what I see, the bigest question new programmers have about the
exception mechanism is about when to use it. They are told vague
generalities but not given anything concrete (they are told to use them
for "errors" and "exceptional situations".) I'm trying to clear out some
of the vagueness. As Stroustrup put it:
? ?... the author of a library can detect run-time errors but does not
? ?in general have any idea what to do about them. The user of a library
? ?may know how to cope with such errors but cannot detect them ? or
? ?else they would have been handled in the user?s code and not left for
? ?the library to find. The notion of an exception is provided to help
? ?deal with such problems.
What Stroustrup is describing above are precondition violations.
I was alluding that there may be more (at least I'm not ready to place
a seal on just those things as constituting all errors).
Exceptions should not be (and in fact, cannot be) used for "all errors,"
unless you define "error" as a precondition violation.
A definition of error that is "failure of or failure to achieve
preconditions, postconditions, invariants" seems much less broad (and
therefor less correct) than "anything that will cause a function to
fail". Of course, "bugs" are not included in the latter.
To me, your two quotes above are equivalent, so neither is less correct
or less broad than the other.
I've been following this thread with a sense of dread, mostly because
I've seen this pop up several times and the same rehashed arguments
are given.
I'm glad you joined in. Sorry that my arguments are rehashed, but I
certainly can't take credit for being the first person to use them. I am
walking in bigger shoes. :-)
Counter example to your claims:
1- Library should throw on every pre-condition violation.
I never claimed that a library should throw on *every* pre-condition
violation. I have only said that if a precondition violation is
detected, then a throw is the most appropriate action.
2- Libraries should not throw on post-condition violations. So, what
should we do when std::new fails to allocate memory? Or when a file
flush fails due to whatever reason (like the USB stick being
removed)?
I think the problem here is in considering these to be post-condition
violations. It is not operator new's responsibility to ensure that the
requested memory is available, nor can operator new possibly know what
to do in such a case. [see my last comment below]
What you say doesn't make sense unless you weaken all pre and post
conditions to drivel, such as weakening operator new to "Maybe it
allocates memory, maybe it doesn't".
The post condition for operator new is that it allocates the memory and
returns a pointer to it. That's a pretty strong requirement, every bit
as strong as its precondition, that the required amount of memory be
available.
As more of a matter of an educated guess, if you want more
maintainable code, then if you have an error condition which is
unlikely to be handled at the caller, and is instead likely to be
handled much farther up the call stack, then use an exception.
Here you are saying the same thing that Stroustrup and I are saying, but
using different words. If the library can solve the problem then fine;
if it can't then the calling code must ensure that the issue never gets
to the library, i.e., it's a precondition for calling the library that
the issue not exist. Now the only question is what should the library
code do if it happens to detect that the precondition was not met?
terminate the app, throw an exception, or leave the behavior undefined.
Clearly, throwing an exception is the best choice.