Why does null check fail even though object is explicitly initialized as null

Question

I have created a custom abstract class, which in turn of course derived classes were also created.

public abstract class AbstractBaseClass
...

public class ChildClass1 : AbstractBaseClass
...

Now, whenever I declare for example AbstractBaseClass baseClass = null, and wherever null checks follow after this initialization, it always fails.

if (baseClass == null)
{
    // this block is never reached - condition always evaluates to false
    // let's say AbstractBaseClass baseClass = null is at line 10
    // even if this condition is at line 11, condition still fails
}

Reason why there is a null check is because there are multiple derived classes, and on some process, I determine which type would it be (e.g. using switch cases). And of course there are invalid cases, in which I expect that the value would be the initialized null.

This is really weird, and I really am expecting that null check would evaluate to true.

What could be the possible causes why this happens (so that I can add more sample code depending on the info as the whole relevant code is quite big), and how should one fix this? Thank you.

EDIT:

Also, debugger value is null.

Oh that's right, as @taffer mentioned, == is overloaded for AbstractBaseClass. Here is that part and other relevant code:

    protected bool Equals(AbstractBaseClass other)
    {
        return Equals(this.SomeUniqueProperty, other.SomeUniqueProperty);
    }

    public override bool Equals(object obj)
    {
        if (ReferenceEquals(null, obj))
        {
            return false;
        }

        if (ReferenceEquals(this, obj))
        {
            return true;
        }

        return obj.GetType() == this.GetType() && this.Equals((AbstractBaseClass)obj);
    }

    public override int GetHashCode()
    {
        return (this.SomeUniqueProperty != null ? this.SomeUniqueProperty.GetHashCode() : 0);
    }

    public static bool operator ==(AbstractBaseClass a, AbstractBaseClass b)
    {
        if (ReferenceEquals(null, a))
        {
            return false;
        }

        return !ReferenceEquals(null, b) && a.Equals(b);
    }

    public static bool operator !=(AbstractBaseClass a, AbstractBaseClass b)
    {
        return !(a == b);
    }

when using the debugger and setting a breakpoint what value actually is in `baseclass`? — Denis Schaf, Mar 19 '19 at 08:33
When I watch the value, it is null, that's why I'm really confused :( — Michael Balser, Mar 19 '19 at 08:35
Show a reproducible example. It can be anything. Is == operator overloaded, for example? — György Kőszeg, Mar 19 '19 at 08:44
@HimBromBeere yes I rebuild the solution many times already. And also, this null check is performed in many places, and currently would break the application logic. — Michael Balser, Mar 19 '19 at 08:44
@MichaelRandall I tried to reproduce with just the bare bones code, but null check succeeds :( https://dotnetfiddle.net/ShbVT1 — Michael Balser, Mar 19 '19 at 08:45
Is it because you can't instantiate an abstract class, what happens if you do the check for if(baseClass == default(BaseClass)) — Daniel Loudon, Mar 19 '19 at 08:48
@taffer yes I forgot about that, I edited the post now to reflect the additional code. — Michael Balser, Mar 19 '19 at 08:54
@MichaelRandall now I was able to reproduce the actual result with the updated code. https://dotnetfiddle.net/rXrojC — Michael Balser, Mar 19 '19 at 08:59
Why would you overload the ``==`` operator in such an unintuitive way? Abstractions like operator overloading can be used to make code concise and elegant but this is clearly an example of how to shoot yourself in the foot. — dumetrulo, Mar 19 '19 at 09:03
This piece of code is quite old now. As I remember, this maybe a combination of Resharper generated code and copy+paste. Makes sense now. — Michael Balser, Mar 19 '19 at 09:06
@RufusL this would definitely produce stackoverflowexception. — Michael Balser, Mar 19 '19 at 09:11

Zohar Peled · Accepted Answer · 2019-03-19T09:20:37.657

Your == overload is wrong, as you are returning false if a is null, ignoring the fact that b could also be null.

What you need to do is return true if both are null, or if a equals b:

public static bool operator ==(AbstractBaseClass a, AbstractBaseClass b)
{
    var isANull = ReferenceEquals(null, a);
    var isBNull = ReferenceEquals(null, b)
    return (isANull && isBNull) || a?.Equals(b) ?? false;
}

Note: In case a is null but b is not, the .? operator will return null, and the ?? operator will return false.

As RufusL wrote in the comments, there's a shorter eqiuvalent code to get the same results:

public static bool operator ==(AbstractBaseClass a, AbstractBaseClass b)
{
    return a?.Equals(b) ?? ReferenceEquals(null, b);
}

if a is null, return true if b is also null. if a is not null, return the result of a.Equals(b).

In case a is not null but b is, your Equals method should return false:

protected bool Equals(AbstractBaseClass other)
{
    return other != null 
        ? Equals(this.SomeUniqueProperty, other.SomeUniqueProperty) 
        : false;
}

Why does null check fail even though object is explicitly initialized as null

1 Answers1

Linked