Зачем приводить ноль перед проверкой, равен ли объект нулю? - PullRequest
12 голосов
/ 23 мая 2010

Я просматривал проект " N-Layered .NET 4.0 Sample Layer App " и наткнулся на некоторый код, который я не понимаю. В этом проекте они часто используют синтаксис, подобный следующему, чтобы проверить аргументы для нуля:

public GenericRepository(IQueryableContext context,ITraceManager traceManager)
{
    if (context == (IQueryableContext)null)
            throw new ArgumentNullException("context", Resources.Messages.exception_ContainerCannotBeNull);

Почему вы приводите null к типу объекта, который вы проверяете на null?

Ответы [ 3 ]

14 голосов
/ 23 мая 2010

Это бессмысленно в приведенном примере.

Хотя это и не применимо в этом случае, иногда возникает необходимость приведения значения null (или, по крайней мере, это было до того, как был добавлен default (T)). Учтите следующее:

void DoSomething(string x) {
    ...
}

void DoSomething(object x) {
    ...
}

DoSomething(null);            // compiler can't infer the type
DoSomething((string)null);    // string type is now explicit
DoSomething(default(string)); // same as previous

EDIT

Просто подумал о другом случае, когда вам придется выполнять приведение при проверке равенства. Если бы у вас был объект с перегруженным оператором ==, который допускал сравнение с двумя ссылочными типами, сравнение с нулем было бы неоднозначным. Однако, поскольку IQueryableContext, скорее всего, является интерфейсом и интерфейсы не могут перегрузить оператор ==, я все еще не вижу веских причин сделать это в приведенном вами примере.

class CustomObject {

    private string _id;

    public CustomObject(string id) {
        _id=id;
    }

    public static bool operator ==(CustomObject lhs, CustomObject rhs) {
        if (ReferenceEquals(lhs, rhs)) { return true; }
        if (ReferenceEquals(lhs, null)) { return false; }
        if (ReferenceEquals(rhs, null)) { return false; }
        return lhs._id == rhs._id;
    }

    public static bool operator !=(CustomObject lhs, CustomObject rhs) {
        return !(lhs == rhs);
    }

    public static bool operator ==(CustomObject lhs, string rhs) {
        if (ReferenceEquals(lhs, rhs)) { return true; }
        if (ReferenceEquals(lhs, null)) { return false; }
        if (ReferenceEquals(rhs, null)) { return false; }
        return lhs._id == rhs;
    }

    public static bool operator !=(CustomObject lhs, string rhs) {
        return !(lhs==rhs);
    }

}

CustomObject o = null;
if (o == null) {
    Console.WriteLine("I don't compile.");
}
6 голосов
/ 23 мая 2010

Я бы не стал сниматься. В этом случае нет причин для этого.

3 голосов
/ 23 мая 2010

Нет причин бросать ноль в данном примере. Это может быть для разборчивости ... Я не знаю, я бы не стал это делать = P

В некоторых случаях [которые не включают случай, описанный в этой теме], вы должны привести к INullable, прежде чем сможете проверить, является ли переменная нулевой. В противном случае вы должны использовать object == default (TypeOfObject) ...

...