Comment 9 for bug 1157828

Nice! Passing the responsibility to the non-null object seems like a good
strategy.

It would need to be extended to cover cases where the non-null object
implements IEquatable as well. And we should look at every special case in
NUnitEqualityComparer and make sure that they will handle null correctly.
Most likely, this will lead to some refactoring too.

Charlie

On Tue, Mar 26, 2013 at 5:09 AM, Meg Gotshall <email address hidden> wrote:

> >From what I recall, the logic for the null checks at the beginning of
> the method is something like:
>
> if (a == null && b == null)
> return true;
>
> if (a == null || b == null)
> return false;
>
>
> Could that be safely replaced with:
>
> if (a == null && b == null) // or ReferenceEquals if you switch for
> clarity
> return true;
>
> if (a == null)
> return b.Equals(null);
> else if (b == null)
> return a.Equals(null);
>
> ?
>
> I don't have the code in front of me, but off the top of my head, I
> can't think of any cases where you would still need to do any of the
> type-specific comparisons that come before the call to a.Equals(b). It
> seems like a relatively safe way to fix the issue without affecting any
> existing calls.
>
> --
> You received this bug notification because you are subscribed to NUnit
> Extended Testing Platform.
> https://bugs.launchpad.net/bugs/1157828
>
> Title:
> EqualityComparer does not respect value-equality for null
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/1157828/+subscriptions
>