¿Por qué está haciendo Resharper la siguiente recomendación?

Mi código es ...¿Por qué está haciendo Resharper la siguiente recomendación?

public static void AssertNotNull<T>(string name, T val) { 
    if (val == null) 
     throw new ArgumentNullException(String.Format("{0} must not be null", name)); 
}

ReSharper está recomendando ...

public static void AssertNotNull<T>(string name, T val) { 
    if (Equals(val, default(T))) 
     throw new ArgumentNullException(String.Format("{0} must not be null", name)); 
}

Fuente

2009-02-26 JeremyWeir

Son esas cosas las que hacen que el respirador valga diez veces el dinero. –

Pregunta interesante +1, solo una cosa podría incluir más información en el título para que la próxima vez sea más fácil decir "¿Por qué resharper recomienda reemplazar val == null con Equals (val, default (T))" Gracias. –

Debido a que no sabe si T es un tipo de valor o tipo de referencia, por lo que hace que el código funcione con ambos.

Fuente

2009-02-26 19:26:20 Bearddo

así que si quería hacer lo siguiente para asegurarme de que es un tipo de ref, ¿qué puse para XXX? public static void AssertNotNull (nombre de cadena, T val) donde T: XXX – JeremyWeir

nm Michael Meadows respondió esa parte – JeremyWeir

En este caso estoy en desacuerdo con Resharper si es por eso que está dando ese error. Piénselo, si T es un int, y el valor IS en realidad es 0 y DEBERÍA ser cero, emitirá una excepción, mientras que si comprueba null, no arrojaría una excepción. – BFree

Me segunda respuesta de Berado, pero añadiría que se puede evitar que esto añadiendo la restricción a continuación:

public static void AssertNotNull<T>(string name, T val) where T : class

Fuente

2009-02-26 19:27:45

gracias, eso tiene mucho sentido – JeremyWeir

Estos dos métodos no son equivalentes. El primero permite AssertNotNull ("foo", 0) mientras que el segundo tira. Creo que Resharper está siendo demasiado entusiasta en este caso.

Fuente

2009-02-26 19:29:43 Greg

Su punto está en el lugar. Resharper lo marca como advertencia (amarillo) de forma predeterminada. Solo quiere advertirle que este método no funcionará como se espera para todas las entradas posibles. –

er, una revisión: AssertNotNull ("foo", 0) no arrojará una excepción, actuará como si fuera un valor nulo, ya que el valor predeterminado para int es 0, por lo que Equals (val, default (T)) evalúa a verdad –

Quise decir que "throw new ArgumentNullException" se ejecutará en el segundo método. ¿Estás de acuerdo? – Greg

Esto, obviamente, no es lo que desea en este caso, sino que sólo está tratando de ser útil, asegurándose de que no se introducen un error al olvidar que los tipos de referencia pueden ser utilizados para T. Como @Michael Meadows dijo, es probable que desee agregar la restricción class al T.

Fuente

2009-02-26 19:30:06 bdukes

Supongo que porque T podría ser un tipo sin referencia.

Fuente

2009-02-26 19:30:29 Tundey

si sabes que T siempre será una clase, luego agrega una cláusula where para decirlo, entonces tu código original estará bien.

public static void AssertNotNull<T>(string name, T val) 
    where T : class 
    { 
     if (val == null) 
      throw new ArgumentNullException(String.Format("{0} must not be null", name)); 
    }

Fuente

2009-02-26 20:13:20

¿Por qué está haciendo Resharper la siguiente recomendación?

Respuesta

Cuestiones relacionadas