Почему брошенный пустой указатель прежде, чем проверить, равен ли объект пустому указателю?
Я просматривал "Доменную Ориентированную.NET N-Layered 4.0 Демонстрационных Приложения" проект и натыкался на некоторый код, который я не понимаю. В этом проекте они часто используют синтаксис как следующее для проверки аргументов в пользу пустого указателя:
public GenericRepository(IQueryableContext context,ITraceManager traceManager)
{
if (context == (IQueryableContext)null)
throw new ArgumentNullException("context", Resources.Messages.exception_ContainerCannotBeNull);
Почему Вы бросили бы пустой указатель к типу объекта, который Вы проверяете на пустой указатель?
3 ответа
В приведенном примере это бессмысленно.
Хотя это не применимо в этом случае, иногда возникает необходимость привести к нулю (или, по крайней мере, это было до того, как было добавлено значение по умолчанию (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
РЕДАКТИРОВАТЬ
Просто подумал о другом случае, когда вы пришлось бы выполнять приведение при проверке равенства. Если бы у вас был объект с перегруженным оператором ==, который разрешал сравнение с двумя ссылочными типами, сравнение с null было бы неоднозначным. Однако, поскольку 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.");
}
Я бы не стал делать слепок. В данном случае для этого нет причин.
В приведенном примере нет причин для приведения null. Возможно, для наглядности... Не знаю, я бы так не делал =P
В некоторых случаях [к которым не относится случай, рассматриваемый в этой теме] вы должны привести к INullable, прежде чем вы сможете проверить, является ли переменная нулевой. В противном случае вы должны использовать object==default(TypeOfObject)...