Re: if(!p) { assert(false); return NULL; } ... ?
On 9/27/2012 1:59 PM, Martin B. wrote:
I'm curious what others think of this pattern:
+ + + +
TX* f(TY* p, ...) {
if (!p) {
assert(false);
return NULL;
}
...
}
+ + + +
I'm not sure whether I should accept it as defensive programming or
think it's just plain superfluous?!
It's a hack. A proper way to handle the situation with non-acceptable
argument value would be to throw an exception, unless, of course, there
is a "nothrow" requirement from the client (caller)...
So I have a function that is required to only accept a non-null pointer,
"documented" by the assert statement, only to have the function fail
"gracefully" should it be passed a NULL pointer. (Obviously, returning
NULL is *only* done in this case, otherwise a valid pointer will be
returned.)
Since we're not offered the specification, we can't judge how close this
code matches them, can we? Trying to divine the requirements from the
code hinges on the assumption that the code correctly implements them.
At the same time judging the code's correctness assumes that the
requirements (specification) is known independent from the code. So,
you got a chicken and an egg problem, AFAICT.
cheers,
Martin
p.s.: While I'm at it, I'll give one of the reasons such things are
explained: Developer had a crash dump where the immediate crash reason
was dereferencing of `p` inside f when it was NULL. Since no one was
able to reproduce it in due time, they added the check "so it won't
crash anymore". Which, yes, it doesn't, but now we have this code and
even longer debugging sessions when the program doesn't do what it's
supposed to do (but doesn't crash).
That's why I called it a hack. Welcome to code maintenance hell!
V
--
I do not respond to top-posted replies, please don't ask