Проверка инициализации C# new () на null?
Я нашел этот фрагмент кода на Кодерс:
private ServiceProvider SiteServiceProvider
{
get
{
if (serviceProvider == null)
{
serviceProvider = new ServiceProvider(site as VSOLE.IServiceProvider);
Debug.Assert(serviceProvider != null, "Unable to get ServiceProvider from site object.");
}
return serviceProvider;
}
}
Мне интересно, есть ли любой возможный способ срабатывания Debug.Assert(serviceProvider != null? У меня сложилось впечатление, что new можно прервать только в результате исключения, и в этом случае утверждение никогда не будет достигнуто.
Ответы 3
Возможно, ServiceProvider переопределяет оператор! = / ==, так что для состояния инвалид сравнение с нулевым значением возвращает истину.
Все равно выглядит странно.
Я бы ожидал, что этот шаблон «проверка на нуль» больше, если бы это был заводской метод, т.е.
SomeType provider = SomeFactory.CreateProvider();
if (provider == null) // damn!! no factory implementation loaded...
{ etc }
Есть еще один случай, о котором стоит знать, но который здесь неприменим (поскольку мы знаем тип, который создаем) ... Nullable<T>; это в основном проблема с дженериками:
static void Test<T>() where T : new()
{
T x = new T();
if (x == null) Console.WriteLine("wtf?");
}
static void Main()
{
Test<int?>();
}
Это покрыто еще здесь.
@David - это относится к заголовку вопроса, поэтому я и включил его ;-p
Я согласен. Если используется обычный оператор! = (Унаследованный от Object), этого никогда не произойдет. Конструктор всегда возвращает ссылку на объект, и, как вы указали, если в конструкторе возникло исключение, точка выполнения полностью оставит свойство.
Я бы проверил, для чего предназначен этот код. Конструктор, конечно, мог оставить сконструированный объект в несогласованном состоянии, и, по-видимому, это то, на что следовало бы протестировать.
Если ваш класс ServiceProvider реализует System.IServiceProvider, вы можете убедиться, что GetService () не возвращает null.
Оба интересных момента (следовательно, +1), которые, как вы правильно утверждаете, здесь не применимы.