Re: Exceptions, Go to Hell!
On Sep 8, 4:47?pm, "joe" <jc1...@att.net> wrote:
Daniel T. 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.
I disagree. Assertions should be used for the above.
... a library that doesn?t know about the purpose and general
strategy of the program in which it is embedded cannot simply exit()
or abort(). A library that unconditionally terminates cannot be used
in a program that cannot afford to crash. (Stroustrup)
It is not up to the library code to make such high level decisions, only
the program's designer should be allowed to make such decisions.
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.
Well you are failing miserably then for you just above suggested that
exceptions were useful for bug control.
I suggested that they are useful for informing users of your library
that they have a problem, since you can't fix it.
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.
What mechanism one uses is strictly personal preference. Of course
though, one may be "trapped" into using C++ exceptions when usage of
the constructs of the language dictate so.
Regardless, there is no single mechanism that can handle *all* possible
problems. Too much of C++ is left as "undefined behavior" for that to be
possible.
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.
Well if you can't grasp the very different level of abstraction, I'll
leave you to your own devices to figure it out. Consider adopting my
"definition" of "error": Anything that can cause a function to fail,
but is not a bug.
If a function is called with correct preconditions, and it satisfies its
postcondition without breaking any invariants, then it can't be said to
fail; unless you have a weird definition of "fail" as well. Now it may
be the case that there is something inherently contradictory in the
precondition/postcondition set such that the function cannot possibly
satisfy the postcondition in some cases, but that doesn't point to a
failure of the function, instead it shows a problem with the design.