2008-12-16 15 views
9

he encontrado este pedazo de código en Koders:Comprobando la inicialización de C# new() para nulo?

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; 
    } 
} 

Me pregunto, ¿hay alguna manera posible la Debug.Assert(serviceProvider != null podría desencadenar? Tengo la impresión de que new solo podría ser cancelado por una excepción, en cuyo caso nunca se alcanzaría la afirmación.

Respuesta

11

Es posible que ServiceProvider anule el operador! = /==, por lo que para un no válido indica que la comparación con null devuelve verdadero.

Parece extraño de todos modos.

+0

Tan cierto. * gag * –

7

que sería de esperar que los ensayos para "nulo" patrón más si se trataba de un método de fábrica - es decir

SomeType provider = SomeFactory.CreateProvider(); 
if(provider == null) // damn!! no factory implementation loaded... 
{ etc } 

Hay otro caso, vale la pena conocer, pero que no se aplica aquí (ya que sabemos el tipo que estamos creando) ... Nullable<T>; esto es principalmente un problema con los genéricos:

static void Test<T>() where T : new() 
{ 
    T x = new T(); 
    if (x == null) Console.WriteLine("wtf?"); 
} 
static void Main() 
{ 
    Test<int?>(); 
} 

Esto se trata más here.

+1

Ambos puntos interesantes (por lo tanto, +1), que, como afirmas correctamente, no se aplican aquí. –

+0

@David: se aplica al título de la pregunta, por lo tanto, por qué lo incluí ;-p –

3

Estoy de acuerdo. Si se usa el operador! = Normal (heredado de Object), esto nunca puede suceder. Un constructor siempre devuelve una referencia de objeto y, como ha señalado, si se arrojó una excepción en el constructor, el punto de ejecución dejaría la propiedad por completo.

Verificaría lo que este código está destinado a hacer. El constructor podría, por supuesto, haber dejado el objeto construido en un estado inconsistente, y eso es probablemente lo que debería haber sido probado.

Si su clase ServiceProvider implementa System.IServiceProvider, es posible que desee comprobar para asegurarse de que GetService() no devuelve nulo.