Messages in this thread | | | Date | Thu, 10 Jul 2003 17:54:28 -0500 | From | "David D. Hagood" <> | Subject | Re: Style question: Should one check for NULL pointers? |
| |
There is an old saying in software design:
"Never check for an error condition that you do not know how to handle."
In other words: if you have identified a possible error condition (such as a NULL pointer), until you have identified a way to meaningfully handle that error condition, simply testing for it is useless.
Now, if you have some function that can return an error code, then testing for NULL and returning an error condition is sensible. But if you have no way to report the error, then what good is the test?
However, if you test for NULL, and log a report when you detect it then deref it anyway (to force an OOPS, in other words throw an exception), then at least there is some meaningful info in the log.
But just doing something like
void foo(void *ptr) { if (!ptr) return;
.... }
just masks the problem.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |