Develop Reference

Check for null in == override

In the following C# snippet I override the == method. _type is a number of type short. So I'm actually saying that two WorkUnitTypes are the same when those two shorts are the same.
public static bool operator ==(WorkUnitType type1, WorkUnitType type2)
{
if (type1 == null || type2 == null)
return false;
return type1._type == type2._type;
}
Because R# warns me, and it is totally clear why, that type1/type2 could potentially be null I'm trying to catch that with the if statement above.
Now I'm getting a StackOverflowException which makes totally sense because I'm actually calling the override.
Question: How do I write this method "correct". How can I catch the case that type1 or type2 can be null?
My best guess: Maybe I'm just misusing == here and checking for equality should be done with the Equals override. But still I think the problem exists. So where is my error in reasoning?

You're looking for the ReferenceEquals() function, which will compare directly, bypassing your operator overload.

In addition to what SLaks said, you likely also want to return true if both are equal to null. So, like this:
public static bool operator ==(WorkUnitType type1, WorkUnitType type2)
{
if (ReferenceEquals(type1, null))
return ReferenceEquals(type2, null);
if (ReferenceEquals(type2, null))
return false;
return type1._type == type2._type;
}

For completeness' sake: you can also cast the two arguments to object. This will use the implementation as defined in object and not your custom one.
In code:
if ((object) type1 == null || (object) type2 == null)

The "is" keyword: there a difference in these methods?

Not really sure about the is keyword, but I think these two are the same. Can anyone confirm this?
public bool Equals(Object obj)
{
if (obj == null) return false;
MyType t = (MyType)obj;
if (t == null) return false;
return true;
}
and the other is...
public bool Equals(Object obj)
{
return obj is MyType;
}

No, they are definitely not equal. The cast to (MyType) will throw InvalidCastException immediately if obj isn't an instance of MyType. The expression will not evaluate to null if the cast fails. as operator exhibits the behavior you are expecting from that cast. My answer to another question discusses this in a bit more detail.

They are not the same. If obj is not MyType, the first version throws an exception, the second version returns false.
And this implementation of Equals() is quite strange. Are you sure you want to consider all instances of MyType as equal?

In the first method, you risk the cast failing and throwing an exception. I think you might be mixed up with the as keyword, which returns null if the cast fails instead. Once that's fixed, the methods would be roughly equivalent:
public bool Equals(Object obj)
{
return (obj as MyType) != null;
}
But the latter is more concise and clear anyway.

Not the same, the 1st version bombs with an InvalidCastException if an object of an unrelated type is passed.
Equals() is supposed to test for value equality, not type equality.

An is expression evaluates to true if both of the following conditions
are met:
expression is not null.
expression can be cast to type.
That is, a cast expression of the form (type)(expression) will complete without
throwing an exception. For more information, see 7.6.6 Cast
expressions. A compile-time warning will be issued if the expression
expression is type is known to always be true or always be false.
From MSDN
The methods are not the same. If obj is not of MyType it will throw an exception while is will not, it will return false.

Result of calling IEquatable<T>.Equals(T obj) when this == null and obj == null?

What should IEquatable<T>.Equals(T obj) do when this == null and obj == null?
1) This code is generated by F# compiler when implementing IEquatable<T>. You can see that it returns true when both objects are null:
public sealed override bool Equals(T obj)
{
if (this == null)
{
return obj == null;
}
if (obj == null)
{
return false;
}
// Code when both this and obj are not null.
}
2) Similar code can be found in the question "in IEquatable implementation is reference check necessary" or in the question "Is there a complete IEquatable implementation reference?". This code returns false when both objects are null.
public sealed override bool Equals(T obj)
{
if (obj == null)
{
return false;
}
// Code when obj is not null.
}
3) The last option is to say that the behaviour of the method is not defined when this == null.

leppie is right. Just to elaborate on his answer (and confirm his suspicion that F# doesn't guarantee this != null): discriminated unions may be marked with the attribute [<CompilationRepresentation(CompilationRepresentationFlags.UseNullAsTrueValue)>] allowing cases to be represented by the value null. Option<'T> is such a type. The None case is represented by null at run-time. (None : option<int>).Equals(None) is syntactically valid. Here's a fun example:
[<CompilationRepresentation(CompilationRepresentationFlags.UseNullAsTrueValue)>]
type Maybe<'T> =
| Just of 'T
| Nothing
[<CompilationRepresentation(CompilationRepresentationFlags.Instance)>]
member this.ThisIsNull() = match this with Nothing -> true | _ -> false
Decompiling ThisIsNull with Reflector shows
public bool ThisIsNull()
{
return (this == null);
}
And the result:
Nothing.ThisIsNull() //true

The reason F# does this (I suspect) to optimize empty lists as null.
By adding this check, it allows one to call an instance method on a null instance without any problems.
See my blog post from a while back.
In C#, this is irrelevant.
To answer the question:
It should return true as both instances are null and deemed equal.

If this is null, the code can't be called, so that case needn't be considered (in C# anyway, there are cases where languages allow a null object to have a method dereferenced though obviously if it internally examines any of its non-existent fields it will error. Consider:
return x.Equals(y);
If x is null, we don't even get to call into Equals for the null check to count.
Hence we need only consider:
public bool Equals(T obj)
{
if(obj == null)
return false;
//logic defining equality here.
}
Where the possibility of both objects being null does come up, is when we are examining them from a static == operator override or from an IEqualityComparer<T> implementation:
public bool Equals(T x, T y)
{
if(x == null)
return y == null;
if(y == null)
return false;
//logic defining equality here.
}
Note that a useful shortcut here if equality can be lengthy to determine (e.g. comparing long strings), then we may take advantage of the fact that identity entails equality - that is something is always equal to itself, even Ayn Rand could figure that out ;) There are also algorithms that make comparing an item with itself quite common, making this shortcut well worth including. In this case the identity comparison already includes the check for both being null, so we leave it out again:
public bool Equals(T x, T y)
{
if(ReferenceEquals(x, y))
return true;
if(x == null || y == null)
return false;
//logic defining equality here.
}

For most methods I assume undefined behavior when called with this==null. That's because most programmers write their code under the assumption that this!=null, which is guaranteed by the C# specification if the calling code is written in C#.
That's why every sane caller of x.Equals(y) should either know for sure that that x is not null, or add a manual null check.
In most cases I wouldn't call Equals directly at all, but instead use EqualityComparer<T>.Default.

I would definitelly go with option 1:
if (this == null)
{
return obj == null;
}
if (obj == null)
{
return false;
}
null object always equals null object.

Sample code is in the MSDN: http://msdn.microsoft.com/en-us/library/ms131190.aspx?ppud=4

If this==null you will get a runtime exception calling Equals() on that object.

Why casting to object when comparing to null?

While browsing the MSDN documentations on Equals overrides, one point grabbed my attention.
On the examples of this specific page, some null checks are made, and the objects are casted to the System.Object type when doing the comparison :
public override bool Equals(System.Object obj)
{
// If parameter is null return false.
if (obj == null)
{
return false;
}
// If parameter cannot be cast to Point return false.
TwoDPoint p = obj as TwoDPoint;
if ((System.Object)p == null)
{
return false;
}
// Return true if the fields match:
return (x == p.x) && (y == p.y);
}
Is there a specific reason to use this cast, or is it just some "useless" code forgotten in this example ?

It is possible for a type to overload the == operator. The cast to object ensures that the original definition is used.

As others said, the type might override the == operator. Therefore, casting to Objectis equivalent to if (Object.ReferenceEquals(p, null)) { ... }.

I believe casting to System.Object would get you around any operator overloading that TwoDPoint might have.

It likely exists to avoid confusion with an overloaded == operator. Imagine if the cast did not exist and the == operator was overloaded. Now the p == null line would potentially bind to the operator ==. Many implementations of operator == simply defer to the overridden Equals method. This could easily cause a stack overflow situation
public static bool operator==(TwoDPoint left, TwoDPoint right) {
return left.Equals(right);
}
public override bool Equals(System.Object obj) {
...
TwoDPoint p = obj as TwoDPoint;
if ( p == null ) { // Stack overflow!!!
return false;
}
...
}
By casting to Object the author ensures a simple reference check for null will occur (which is what is intended).

This might have been part of a larger sample where the == operator was overloaded. In that case, using obj == null could have resulted in StackOverflow if TwoDPoint.Equals(object) was invoked as part of the == definition.

Best way to handle null when writing equals operator [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do I check for nulls in an '==' operator overload without infinite recursion?
When I overload the == operator for objects I typically write something like this:
public static bool operator ==(MyObject uq1, MyObject uq2) {
if (((object)uq1 == null) || ((object)uq2 == null)) return false;
return uq1.Field1 == uq2.Field1 && uq1.Field2 == uq2.Field2;
}
If you don't down-cast to object the function recurses into itself but I have to wonder if there isn't a better way?

As Microsoft says,
A common error in overloads of
operator == is to use (a == b), (a ==
null), or (b == null) to check for
reference equality. This instead
results in a call to the overloaded
operator ==, causing an infinite loop.
Use ReferenceEquals or cast the type
to Object, to avoid the loop.
So use ReferenceEquals(a, null) || ReferenceEquals(b, null) is one possibility, but casting to object is just as good (is actually equivalent, I believe).
So yes, it seems there should be a better way, but the method you use is the one recommended.
However, as has been pointed out, you really SHOULD override Equals as well when overriding ==. With LINQ providers being written in different languages and doing expression resolution at runtime, who knows when you'll be bit by not doing it even if you own all the code yourself.

ReferenceEquals(object obj1, object obj2)

#neouser99: That's the right solution, however the part that is missed is that when overriding the equality operator (the operator ==) you should also override the Equals function and simply make the operator call the function. Not all .NET languages support operator overloading, hence the reason for overriding the Equals function.

if ((object)uq1 == null)
return ((object)uq2 == null)
else if ((object)uq2 == null)
return false;
else
//return normal comparison
This compares them as equal when both are null.

Just use Resharper to create you Equals & GetHashCode methods. It creates the most comprehensive code for this purpose.
Update
I didn't post it on purpose - I prefer people to use Resharper's function instead of copy-pasting, because the code changes from class to class. As for developing C# without Resharper - I don't understand how you live, man.
Anyway, here is the code for a simple class (Generated by Resharper 3.0, the older version - I have 4.0 at work, I don't currently remember if it creates identical code)
public class Foo : IEquatable<Foo>
{
public static bool operator !=(Foo foo1, Foo foo2)
{
return !Equals(foo1, foo2);
}
public static bool operator ==(Foo foo1, Foo foo2)
{
return Equals(foo1, foo2);
}
public bool Equals(Foo foo)
{
if (foo == null) return false;
return y == foo.y && x == foo.x;
}
public override bool Equals(object obj)
{
if (ReferenceEquals(this, obj)) return true;
return Equals(obj as Foo);
}
public override int GetHashCode()
{
return y + 29*x;
}
private int y;
private int x;
}

But why don't you create an object member function? It can certainly not be called on a Null reference, so you're sure the first argument is not Null.
Indeed, you lose the symmetricity of a binary operator, but still...
(note on Purfideas' answer: Null might equal Null if needed as a sentinel value of an array)
Also think of the semantics of your == function: sometimes you really want to be able to choose whether you test for
Identity (points to same object)
Value Equality
Equivalence ( e.g. 1.000001 is equivalent to .9999999 )

Follow the DB treatment:
null == <anything> is always false