Re: Question on vector at()
On Mar 14, 6:22 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Juha Nieminen wrote:
Alexander Dong Back Kim wrote:
try
{
return _appleBox.at(index);
}
catch (out_of_range e)
{
return ???;
}
Perhaps a different design could be better here?
Usually indexing out of boundaries means one of two things:
1) It's an error, ie. a bug in the code. In this case an
assert() is usually better than throwing (because you can
get the whole call stack easily with a debugger).
<gasp> Strongly disagree. </>
Huh? You have code which you've just proven doesn't work, and
you want it to continue doing incorrectly whatever it was doing?
When you detect an "impossible" state in the code, the only
correct thing to do, nine times out of ten, is to abort the
program as soon as possible, rather than continue stumbling on,
without really knowing whether the results are correct or not.
(This obviously depends somewhat on the domain. In process
control, and especially with critical systems, not aborting
would almost amount to criminal negligence. At the other
extreme, in games programs, the worst thing that could happen if
you don't abort is that the program crashes, which comes out to
about the same, so aborting is probably wrong, at least in
released code. Most programs, however, are probably closer to
the first situation---they do something whose results matter,
and no results are better than incorrect results.)
[...]
I can't think of many applications where at() throwing an
exception would be in any way a desirable thing. (As
mentioned, to catch programming errors IMO using assert() is
better.)
Huh? The exception is *exactly* the right solution, for the
reasons red floyd already explained.
If you've detected a situation which can only be the result of a
programming error, i.e. if you've detected that some pre- or
post-condition or some invariant doesn't hold, then you can have
no confidence in whatever the program does from then on. In
such cases, the correct procedure is almost always to abort, so
that higher level corrective action can occur.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34