¿Debo suprimir CA1062: Validar argumentos de métodos públicos?

Question

Recientemente he actualizado mi proyecto a Visual Studio 2010 de Visual Studio 2008.

En Visual Studio 2008, esta regla de análisis de código no existe.

Ahora no estoy seguro de si debo utilizar esta regla o no.

Estoy construyendo una biblioteca de código abierto por lo que parece importante para proteger a la gente de hacer errores. Sin embargo, si todo lo que voy a hacer es ArgumentNullException tiro cuando el parámetro es null, parece que la escritura de código inútil ya ArgumentNullException será lanzado incluso si no voy a escribir ese código.

EDIT: Además, hay un problema de rendimiento que debe ser abordado. Comprobación de null en cada método público puede causar problemas de rendimiento.

¿Debo quitar esa regla o fijar las violaciónes?

Answer 1

Eso depende. La convención al utilizar ArgumentNullException es incluir el nombre del argumento nulo en la descripción. Por lo que la persona que llama sabrá exactamente lo que salió mal.

La fuente de un NullReferenceException (que es lo que sucederá si no lo hace validar) puede ser fácil de detectar, pero si el método es complejo, puede ser más difícil. Usted puede terminar en una línea de código en múltiples referencias podrían ser nulo.

En lo personal prefiero tener métodos públicos lanzan ArgumentNullException si no pueden manejar la entrada nulo para el argumento dado, ya que permite un comportamiento consistente, sin importar cómo se implementa el método.

En respuesta a editar: En mi opinión, es más importante proporcionar un conjunto coherente de interfaces con pocas sorpresas que la optimización de cada línea de código. Mi conjetura es que en la mayoría de los casos, la sobrecarga de rendimiento del cheque nulo no será significativo. Si no lo hace llegar a ser un problema (como en perfilar lo dice) Me gustaría considerar el cambio de la misma. De lo contrario, no lo consideraría un problema en este punto.

Answer 2

mantener esta regla en porque decidimos que era siempre es mejor consultar parámetros en su primera entrada en su código. De esta manera, cuando la persona que utiliza el código obtiene la excepción del contexto en el que será mejor. Alguien que no tiene su código fuente, por ejemplo, verá que la excepción fue lanzada en el código y puede presentar un informe de fallo que por ello perder su tiempo y el de ellos.

Answer 3

En mi humilde opinión Nº Comprobación de los nulos casi nunca va a ser el cuello de botella en su aplicación. (Y en la que en un caso donde millones es significativo, lo encontrará con su generador de perfiles y quitar que un caso).

La otra pregunta que se debe formar en su mente es "es arrojar nueva NullReferenceException () realmente la mejor manera de manejar el error?" A menudo se puede manejar las cosas mejor que eso (aunque sólo sea para proporcionar un mejor informe de error al usuario y / o usted mismo para fines de depuración). En muchos casos código puede manejar con gracia nulos, lo que hace innecesario para que esto sea un error en absoluto.

editar

Para responder a su edición: cheques nulos realmente no toma mucho tiempo. La sobrecarga por el simple hecho de llamar a un método será decenas si no cientos de veces más que un cheque nulo. El único lugar donde un cheque nulo hará ninguna diferencia significativa se encuentra en un lazo grande, apretada en la que está haciendo muy poco más. Esta situación no sucede muy a menudo -. Por lo general va a comprobar si hay un nulo y luego hacer algo relativamente caro con esa referencia

No hay ninguna situación en la que un accidente o el fracaso es una buena cosa. Es siempre mejor "lento hacia abajo su aplicación" con cheques nulos de chocar y perder los datos de sus clientes.

Así que no optimizar prematuramente su código. Escribirlo así, ser fácil de mantener y robusto, a continuación, perfil para ver dónde están los cuellos de botella. He estado programando desde hace 28 años, siendo muy liberal con cheques nulos, y tengo no encontró que un cheque nula fue la causa de un problema de rendimiento. Por lo general es cosas como hacer un montón de trabajo innecesario en un bucle, usando un O (n ^ 3) algoritmo donde enfoque un O (n ^ 2) es posible, en su defecto para almacenar en caché los valores caros a cálculo, etc.