Re: a missing feature in VC debugger
On Mon, 10 Jul 2006 00:53:03 GMT, "David Ching" <dc@remove-this.dcsoft.com>
wrote:
I wouldn't say ASSERT is for things that "have to be". Instead, it is for
things that "are expected".
I think it's "have to be," in the sense a failed assertion represents (or
should represent) a logical impossibility or a specification violation.
IOW, the programmer (more rarely, the compiler) messed up somewhere, and
the failed assertion represents a bug. To me, "expected" implies there are
multiple legitimate outcomes, and in such cases, assertions (alone) are the
wrong tool.
When I'm using unfamiliar API's or don't know
well a codebase, I ASSERT all over the place to test my assumptions. But
that doesn't mean I want my code to crash if these assumptions prove
invalid, since I'm not sure and don't have the entire codebase in mind. So
I do both ASSERT and add an if() to make sure.
Sometimes if an ASSERT fails, it is OK in the larger scheme of things... I
will often remove the ASSERT as these become more apparent. But sometimes
an ASSERT signals the first symptom of an undesired chain of events. It's
valuable to know when the problem initially started, and the ASSERT does
that. The if() should still allow the condition, but other changes could
potentially be made to avoid or reduce the occurrence of this undesired
condition.
It sounds like you're using assertions as a sort of notification mechanism
for conditions that can exist in correct programs. That's fine as long as
it isn't done at the expense of real error handling.
VERIFY() is just shorthand for
BOOL b = some_function();
ASSERT (b);
are is therefore just as valid as ASSERT is.
As long as the VERIFY user understands the validity hinges on there being
no legitimate failure mode, then it's OK. For VERIFY to be valid, the
function must be defined to return true given everything that can determine
its outcome, such that you are able to know all these things at compile
time. That is, if the success of the function depends on x, y, and z, which
could be parameters, resource availability, etc, then the logic of your
program should dictate that x, y, and z are nominal when you call the
function, regardless of the current state of the program environment at
runtime. If you can't know all those things, then it's wrong to use VERIFY.
For example:
VERIFY(f());
// Do something that depends on the success of f().
Even if the code worked perfectly during the test phase, if f() depends on
anything that can vary from run to run, such as memory availability, it can
still fail out in the field, possibly in very obscure ways.
Just my $0.02. I think this ASSERT topic has come up in the past and
reached "reglious war" status.
Probably so. As the WOPR concluded at the end of "WarGames", the only way
to win that game is not to play, or something like that. :)
--
Doug Harrison
Visual C++ MVP