[...]
(3) When an error does occur in the wild, the program should handle it
as gracefully as possible. If an exception can be thrown, it is
preferable to a crash, unless there is an explicit reason that even a
stack unwind would unacceptable.
And this is where you seem to have misunderstood something.
Throwing an exception is NOT an acceptable way of handling an
error in the wild, since it means that the error might go
unnoticed. Once the error has occurred (even before it has been
detected), the program is functionally incorrect. And
gracefully incorrect is still incorrect---the most important
thing is to ensure that the surrounding environment knows that
the program is incorrect, so that it can take the appropriate
actions. Nothing else really matters. (There are special
cases, e.g. like games, where it is preferable to attempt to
"hide" the error, but I don't think that they're that common.)
Stop and think about it for a minute. Getting a core dump (an
assertion failure) from your editor is certainly not a pleasant
experience. But would you prefer that it stumble on, and
perhaps overwrite all of your file with wrong data, rather than
getting an ugly error message, and probably loosing everything
you've done since the last checkpoint---with a modern editor,
say in the last 5 or 10 seconds?
(4) Different concepts should have different names. As an example, the
name "assert" has already been tasked with identifying conditions that
are known, not just expected, to be true. Assertions are therefore
suitable for documenting and verifying class invariants, but not for
verifying prerequisites.
I'm not sure what you mean by "prerequisites" here. In the
context of the program, you "know" that no one will call your
function with an illegal argument, since the contract you give
forbids it. In the same way you "know" that no one will
overwrite your object with memcpy, thus violating your class
invariants. In both cases, you use assert() to detect the
error, since it will terminate the program most rapidly, and in
a way that the surrounding environment cannot possibly consider
"correct". (At least, that's the intent of assert(). And the
way it works under Unix, and I'm pretty sure Windows.)
Is it possible that the problem was not the lack of a
debugger, but the fact that you were already more comfortable
with the debugger than with alternative solutions? Almost all
of my coding for the past six months has been on Linux, using
gcc. I have rarely used gdb, and then mostly as an
"archaeological" tool to understand code that had been
evolved, rather than designed.
There are different ways to use the debugger. I have no
hesitation about using it for a post-mortem. I also have no
problem with its use *if* the programmer, reflecting on the
code, comes to a point where he feals that 1) the variable in
question must have such and such a value, but 2) if it did, the
observed results aren't possible. (In that case, there's
obviously an error in his thinking---I can see using the
debugger to decide whether the error is upstream or downstream
of this critical point.) In practice, I personally find this
second case very, very rare, however. Individual components
should be simple enough that such problems don't occur within
them, and of course, you log at the interface between
components, so you can get that information from the process
logs. (This probably doesn't hold for shrinkwrapped software.)
That doesn't justify people who use the debugger instead of
thinking. And I know that in a learning environment, until
someone had learned to write at least small applications
correctly, I wouldn't allow access to a debugger. But I have no
problem with an experienced, professional programmer using it
for post-mortems, or even occasionally interactively. While
programs should be correct by construction, none of us are
perfect, and all software development processes do provide means
for double-checking the programmers work. Systematically.
