空检查对于非空值返回true

Question

Having an odd problem. It's happened a few times over the years, but I've never been able to figure out why. Always solved it by rearranging the code I had in place, but would like to know is there's a more proper way of dealing with it, or at least figuring out what's behind it.

Non-working version:

public bool CaptureFrame(ArrayCache cache)
{
    if (cache == null)
        throw new ArgumentNullException("cache");

    DataArray frame = cache.CacheData;

    if (frame == null)
        throw new ArgumentNullException("cache.CacheData");


    // do stuff
}

Working version:

public bool CaptureFrame(ArrayCache cache)
{
    if (cache == null)
        throw new ArgumentNullException("cache");

    if (cache.CacheData == null)
        throw new ArgumentNullException("cache.CacheData");

    DataArray frame = cache.CacheData;


    // do stuff
}

The problem is this: frame is not null (at least according to the debugger, and by any measure I can trace of the code), however when it does the if (frame == null) check, it comes out true and throws the exception. I rewrote to check cache.CacheData and it works fine, but it really shouldn't make any difference to the code logic.

I managed to find one other question on the site with a similar problem, which ended up being related to the == and != operators being overloaded. Those operators are not overloaded for the class in question in my code, and it's a standalone class so there's nothing for it to inherit.

Edit: John Saunders requested code for the CacheData property:

private DataArray cacheData;

public DataArray CacheData
{
    get
    {
        return cacheData;
    }
    set
    {
        cacheData = value;
    }
}

Answer 1

looks like you are mapping the exception in the non working one then calling DataArray frame = cache.CacheData; but what if cache.CacheData if null then you are assigning it to DataFrame.. it's always best in my opinion to do the Check for null first before assigning or assuming your second one looks fine.. prehaps instead of throwing an exception maybe you could trap the exception and try some test cases for both scenarios