Re: a missing feature in VC debugger
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:dnu2b211o15sla7up2hmmu2mnfmc0gq05h@4ax.com...
But all use of ASSERT boils down to tests that are removed from release
builds. If you are going to handle the errors "gracefully" anyway, I'm not
sure I see a whole lot of reason to use ASSERT; it seems like a
contradiction to me. That is, if I'm going to look for null pointers in
code and handle them, that's an expected condition, and I wouldn't assert
on it. The ASSERT macro is for things that "have to be".
I wouldn't say ASSERT is for things that "have to be". Instead, it is for
things that "are expected". 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.
However, I've always questioned the validity of VERIFY. For example,
consider the typical VERIFY:
VERIFY(some_function());
Now some_function is usually a function that could fail due to reasons
that
are entirely unpredictable, such as running out of some resource such as
memory. So to use VERIFY in this context is to say, "I kinda sorta care
about errors, but not too much." At least most ASSERTs seem to be properly
written and involve conditions that are either true or false independent
of
processing beyond the immediate condition; ASSERT(p != NULL) is an example
of that.
VERIFY() is just shorthand for
BOOL b = some_function();
ASSERT (b);
are is therefore just as valid as ASSERT is.
Just my $0.02. I think this ASSERT topic has come up in the past and
reached "reglious war" status.
-- David