Re: I keep running into long term c++ programmers who refuse to use exceptions
"Nevin :-] Liber" <nevin@eviloverlord.com> wrote:
"Daniel T." <daniel_t@earthlink.net> wrote:
Your not quite there IMHO, but you are close. I suggest you read up
on design by contract. Exceptions should be used when contracts are
broken.
If it is a contract violation due to a programming error, it should be
an assertion, not an exception. Exceptions can be part of the
contract.
All contract violations are due to programming error. The contract
defines normal (correct) program control flow. Exception handling is not
for normal control flow, it is for error handling.
"If an exception is expected and caught so that it has no bad effects on
the behavior of the program, then how can it be an error?" -- Stroustrup
The problem with assertions is that in some domains, aborting the
program is unacceptable. Exceptions provide a means of cleaning up,
maybe saving some state and restarting or whatever. When library code
finds an error, it cannot take it upon itself to abort the program
without giving the calling code an opportunity to clean up. The function
author should not make assumptions about how the calling code wants to
handle an error.
Interestingly, I was reviewing some old posts of mine and saw that I
held your position (contract violations should be met with assertions,)
back around 2001 or so. I guess I changed my mind in the intervening
nine years.
Both vector and deque have member-functions called "at()" and these
functions are guaranteed to return the value at a particular index
within the container. In order for the function to be able to meet
its guarantee, it requires that the parameter passed in refers to an
element in the container. Giving a bad parameter is a requirement
violation, the function cannot do its job, so it throws an exception.
The way I see it, an out of range index passed to operator[] is a
contract violation, while an out of range index passed to at() is
perfectly acceptable.
class Foo {
std::vector<int> vec;
public:
// other functions
int getValA(int idx) const {
if (0 <= idx && idx < vec.size())
return vec[idx];
return 0;
}
int getValB(int idx) const {
try {
return vec.at(idx);
}
catch (std::out_of_range) {
return 0;
}
}
};
(I used two returns instead of a result variable just for you. :-)
Both getValA and getValB have the same contract, but you seem to be
asserting that getValB is "perfectly acceptable." Do I understand you
correctly?
... such use of exceptions can easily be overused and lead to
obscure code. Whenever reasonable, one should stick to the
"exception handling is error handling" view. When this is done, code
is clearly separated into two categories: ordinary code and
error-handling code. This makes code more comprehensible.
-- Stroustrup
Stroustrup does remind us that the real world is a messy place and
sometime code gets messy too, but the primary point remains. Be
reasonable... use exceptions to flag errors, and fix errors when they
are found.
Please consider reading (or re-reading) "The C++ Programming language"
section 14.5.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]