Internet Explorer 8 is full of surprises.

mstefan wrote:



BruceMorgan wrote: And sprinkling many redundant / unnecessary null checks throughout the code can hurt overall performance.

I have a quibble with the "unnecessary" part of that comment. I'm an adherent to defensive programming, where there is no such thing as an "unnecessary" check to make sure you're not dereferencing a null pointer. Certainly I would agree that redundant checks are wasteful, but I've always written code from the perspective that a function should never trust its inputs. A program that performs a few extra instructions to always validate the parameters its passed is preferable to one that doesn't, and crashes.

I'm sure that there's folks that would disagree with this and consider that style of coding to be wasteful, but I've always held to the philopsophy that safety and correctness trumps performance. Of course, you always want your software to run efficiently; but in my experience, shortcuts ("Oh, I don't need to check that pointer being passed to me, I know it'll never be null") always get you in the end, eventually.

And what if the pointer is NULL?  What do you do then?  Nothing?  Return a failure and hope the caller can cope with it?

If the contract is that you should never be passed a null pointer, and then you are passed one, someone is breaking the contract of your interface.  Better to AV and identify the problem early, or get lots of Watson dumps.

Obviously, as Bruce pointed out, this is only the case when there's a strict contract that you should never receive a null pointer as an argument.  You wouldn't do this with an API.

mstefan wrote:



BHpaddock wrote: And what if the pointer is NULL?  What do you do then?  Nothing?  Return a failure and hope the caller can cope with it?

If you code defensively, then the caller must be able to handle a failure. I disagree with the notion that it's acceptable, or worse, desirable for a program to simply fault out. While that can be useful for developers, it only detracts from the user experience. Is a cryptic "unhandled exception" dialog -- immediately followed by all of their work being dumped down the bit bucket -- the best that we can do when we make a mistake in our code?

What's better?  The application gets into an unpredicted state and things just stop working, and eventually crashes in some unrelated piece of code, spins indefinitely, etc.

Or the program crashes, is caught by Watson, and the user is presented with a "Please install update XYZ to fix the problem" dialog.

Then again, that should never happen, because your methods/interfaces should be annotated properly and nobody will be calling you with NULL if you don't accept that input.  If they try to, they'll get a PREfix error before they can even check the code in.

As we said, if an exposed API doesn't check its inputs, as is likely happened here, then it's a bug.  Of course, the situation can be more complex, too.  The bug could be that the caller is calling function A with a pointer, function A is null'ing it out unexpectedly, and then the caller passes the same pointer to function B.

Having function B notice the null input and return an error probably doesn't buy you anything, since the caller didn't realize he could ever be passing a null value there.  Maybe somebody changed Function A and introduced that behavior, maybe intentionally or maybe by accident.  Perhaps function A was supposed to initialize the pointer, and the caller just checks if (SUCCEEDED(hr)), but then someone came along and added an S_FALSE return that leaves the out param blank.  In any case like that, covering it up it just makes it harder to find and debug.

Of course, in an ideal world that would never happen, and software wouldn't have bugs.  Sadly, that's not the world we live in.