Re: Question on vector at()
On Mar 17, 3:22 am, Jeff Schwab <j...@schwabcenter.com> wrote:
Juha Nieminen wrote:
Jeff Schwab wrote:
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 re=
d
floyd already explained.
Could you please explain to me why is that?
I think red floyd already explained it as well as I could.
I didn't see where he explained anything except how an exception
works.
If indexing out of boundaries at some place is an indication of a
programming error, ie. a bug, the best course of action is to report
immediately about this detected error, at the place where it happens.
That may be the best place to for the error to be detected,
but it's not necessarily the right place for it to be handled.
That's not what he said. He said it's the best place to report
the error. Where you have a complete stack trace and a maximum
of other information. Anything you do after detecting the error
may loose information or degrade the situation.
In particular, part of the code you snipped showed that the
index was originally passed to the OP's function from some
client. The error is almost certainly in the client code, not
the OP's class, so it is the client who needs to be notified.
Let's see if I've got this right. The client code is hosed, to
the point of provenly being incapable of even providing a
correct argument, and you're saying that it's the most
trustworthy place for the error to be handled. There's
something that I don't understand there. The exception *must*
propagate at least beyond the client code which was corrupted.
Without executing any code in the corrupted client. Including
destructors.
That's sounds like abort, to me. It's certainly not exceptions.
Maybe the client would like to log the error but keep the
program running, or maybe the client would like to terminate
the program altogether. This is the not for the OP's class to
decide.
The client has proven himself incapable of deciding. Someone
has to decide. By aborting, you push the decision up to a
higher level.
assert() is exactly the tool designed for this:
Nope. Assert is for documenting that a particular condition
is impossible.
Exactly. And the impossible has just happened. So all bets are
off.
Assert is frequently abused to verify prerequisites, but an
assertion failure really is, by definition, an internal error.
And calling a function while failing to meet the preconditions
isn't an interal error?
It terminates the program immediately,
And that's what you want your client to see? Your library
crashing the whole program?
Better that, than silently giving a wrong results. Maybe
causing the rods to be pulled out of the reactor, and resulting
in a nuclear meltdown. (My view of this may be prejudiced
because I've worked on critical systems in the past. I
particularly remember the locomotive brake system, where the
emergency brake system which was used when our system detected
an error actually cut all power to the processor. They weren't
taking any chances of our doing something wrong.)
and with the aid of a debugger
Any plan to spend time in the debugger is a self-fulling prophecy.
Anyway, you're missing the point: The bug isn't in the OP's
code, it's in the client code, which he may not have, in which
case he cannot run in his debugger.
I think you're missing the point. The error is somewhere in the
process. We don't know where, but we can no longer count on the
process doing the right thing.
you can see the whole stack trace and the values of the
variables exactly when the error happened. This way the
programming error can be fixed, and the indexing out of
boundaries will not happen anymore.
By the time you see a stack trace, you're already working
backwards. The best tools for finding and tracking logical
errors are compilers and unit tests. It is uncanny how the
people who are best with the debugger are the worst
developers. (That's not meant as a dig at you, btw; I have no
idea what your day-to-day code looks like, and I'm not in a
position to criticize it.)
Debuggers are useful for post-mortems. A stack trace. That's
about it, but that's still something. (That's not strictly
true. I actually had a case the other day where I found the
debugger was really useful on running code. First time in about
twenty years.)
I think you're putting too much emphisis on the debugger part.
The important aspect is that if you couldn't count on the client
code giving you a correct argument, how can you count on it
doing correct error handling.
Suppose you are using some library code, you pass it a bad
value (we all make mistakes), and then at run-time you see
(shiver) an assertion failure. The stack trace shows you
where the error nominally occurred, and what the call-stack
was at the time. You didn't write the functions at the top or
the bottom of the stack trace, but you some of your own code
somewhere in the middle; you therefore crank up the debugger
(you poor, misguided soul) so that you can figure out where
the root cause of the error is. Until you figure out where
the bad value originated, you don't know whether or whither to
direct your bug report. (You don't know that the real problem
is anywhere near where the assertion error occurred, because
the library is abusing assert() to serve as a prereq check.)
That's a fact of life. I've had to handle assertion failures
which were ultimately due to an uninitialized pointer in some
totally unrelated code. The clients data were completely hosed.
To figure out where the error actually originated, you have to
walk through the code (starting where?) in the debugger, step
by step, over who knows how many LOC, until you see the
assertion error.
No. You start by reasoning about the error. And by going to
the log, and seeing what happend before. If the error is caused
by data corruption (all too often the case), you then try and
reproduce it. Until you can reproduce it, you can't fix it.
Generally, once I've determined the cause of the error, from the
stack walkback, I don't use the debugger any more. But that's
really not the issue. The point I think Juha was making is that
if the client code catches the exception, and masks it, you
can't even determine what the cause was, so you don't really
have the information necessary to begin trying to reproduce it.
In the worst case, the error disappears completely, the program
outputs a wrong result, and nobody is even aware of it.
Then you usually have to do it again, because you still
haven't found the root cause, for the same reason you (or
someone else) wrote incorrect code in the first place.
Stepping through code takes O(N) time with the amount of code
involved. It is quite possibly the single least efficient way
of finding and fixing errors that is still in common use.
It's true that just ignoring them, and using the wrong results,
requires less effort on the part of the developers.
I can't even begin to imagine why throwing an exception
instead, and catching it somewhere else than right where the
error happens, would be a better idea.
The error goes to whomever believes they can catch it.
And you trust them, given that they're also the ones who
provided the wrong argument in the first place.
The only advantage of throwing an exception is that the
program could, if so designed (which is often *very*
laborious), continue without interruption.
But sometimes *very* [sic] necessary.
Usually, such aspects are handled as a system level, outside of
the process. (At least, I've never seen a system in industry
where they weren't, and the same thing has held for all of the
server software in the commercial applications I've seen. About
the only exception to this rule has been light weight GUI front
ends, which don't calculate or decide anything, but just
display.)
However, what would the program do in that case? A bug has
been detected,
An exception does not necessarily indicate a bug.
It shouldn't ever indicate a programming error. That's not its
role.
It may just indicate some input error, or other exceptional
condition. (In the case of an index being passed down, I
agree that the index probably should have been validated
before an exception became necessary.)
Which is all Juta is saying. It's hard to imagine a case where
an exception is the desired behavior for an array bounds error.
and now the program knows that function is flawed, the data
is incorrect, and nothing that function returned can be
relied on.
For better or worse, sometimes it has to. Suppose a plane's
on-board GPS software encounters an error. Should the whole
on-board computer just give up and let the plane drop from the
sky?
The whole on-board computer should just give up, noisily, so
that the backup system can take over, and so that in the worst
case, the pilot knows that he cannot count on it, and resorts to
some alternative. This is much preferable to a system which
informs the pilot that he has 1000 ft altitude, and should
descend 500 ft in the landing approach, when he's really only
200 ft above the ground.
Of course not; it should report to the error that the GPS is
wonky, but do the best it can to keep the plane in the air.
Have you ever actually worked on such systems? In the end, it's
the pilot's responsibility to keep the plane in the air, and
anytime the software isn't sure of doing the right thing, it
should abort, letting the backup systems take over (where the
ultimate backup system is the pilot). In such cases, giving
wrong information or doing the wrong thing is worse than giving
no information or doing nothing.
This example is probably more extreme than the OP's AppleCart,
but the principle is the same. Once, while I was working for
a server company, our manager was very proud of our product's
nine-minute fail-over time. We then found out it wasn't good
enough, and I was cranky -- "What do they expect from us?" --
until I found out that the servers were being used to route
calls at an emergency response center. Nine minutes are a
long time to wait when your child is choking on something. A
crash is sometimes just not an option, and post-mortem debug
would not have been enough.
Many of the systems I've worked on in the past have had
contractual penalties for down time. It's fairly usual
procedure in many fields.
Client code seeing an assertion failure is a Very Bad Thing,
even if no one actually plummets to their death as a result.
Not seeing an assertion failure when the program is wrong is an
almost sure guarantee of the plane doing something wrong.
Even if the client does something wrong (again: We all make
mistakes), the least your library can do is give them a chance
to handle the exception.
That buggy function is completely useless.
You don't know that.
You don't know anything about it. You can't take chances.
What exactly is the right course of action in this case?
Only the caller knows.
You do know that the caller isn't behaving correctly. How can
you count on him doing the right thing in terms of error
recovery, when he wasn't capable of doing the right thing when
he passed you the arguments? Has he somehow, miraculously,
fixed himself.
(And how does it differ from a simple assert?)
It gives the application an opportunity to handle the exception, as
opposed to aborting the program.
The error must be propagated up to a point outside of the
process. That's the only place where there's a reasonable
chance of it being handled correctly. (Note that most systems
or applications---and all critical systems and
applications---consist of more than a single program.)
--
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