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

Question

Recientemente actualicé mi proyecto a Visual Studio 2010 desde Visual Studio 2008.

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

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

Estoy creando una biblioteca de código abierto, por lo que parece importante evitar que las personas cometan errores. Sin embargo, si todo lo que voy a hacer es arrojar ArgumentNullException cuando el parámetro es null, parece que escribir código inútil ya que ArgumentNullException se lanzará incluso si no escribiré ese código.

EDITAR: Además, hay un problema de rendimiento que debe abordarse. Verificar null en todos los métodos públicos puede causar problemas de rendimiento.

¿Debo eliminar esa regla o corregir las infracciones?

Answer 1

Eso depende. La convención al usar ArgumentNullException es incluir el nombre del argumento nulo en la descripción. Entonces la persona que llama sabrá exactamente qué salió mal.

El origen de una NullReferenceException (que es lo que sucederá si no se valida) puede ser fácil de detectar, pero si el método es complejo, puede ser más difícil. Puede terminar en una línea de código donde las referencias múltiples podrían ser nulas.

Personalmente prefiero que los métodos públicos arrojen ArgumentNullException si no pueden manejar la entrada nula para el argumento dado, ya que permite un comportamiento consistente sin importar cómo se implementa el método.

En respuesta a la edición: En mi opinión, es más importante proporcionar un conjunto consistente de interfaces con pocas sorpresas que la optimización de cada línea de código. Creo que en la mayoría de los casos, la sobrecarga de rendimiento de la verificación nula no será significativa. Si resulta ser un problema (como lo dice el perfil), consideraría cambiarlo. De lo contrario, no lo consideraría un problema en este punto.

Answer 2

Mantenemos esta regla porque decidimos que siempre era mejor verificar los parámetros en su primera entrada en el código. De esta forma, cuando la persona que usa su código obtiene la excepción, el contexto será mejor. Alguien que no tenga su código fuente, por ejemplo, verá que la excepción fue arrojada en su código y puede presentar un informe de error en su contra por perder su tiempo y el de ellos.

Answer 3

En mi humilde opinión La comprobación de nulos casi nunca va a ser el cuello de botella de rendimiento en su aplicación. (Y en el caso de uno en un millón donde es significativo, lo encontrará con su generador de perfiles y eliminará ese caso).

La otra pregunta que debe formarse en su mente es "¿es realmente nueva la NullReferenceException() la mejor manera de manejar el error?" A menudo puede manejar las cosas mejor que eso (incluso si solo proporciona un mejor informe de error al usuario y/o usted mismo para fines de depuración). En muchos casos, el código puede manejar nulos con elegancia, por lo que no es necesario que sea un error.

edición

para responder a su edición: cheques nulos realmente no toma mucho tiempo. La sobrecarga para simplemente llamar a un método será decenas si no cientos de veces más que una verificación nula.El único lugar donde una verificación nula marcará una diferencia significativa es en un bucle grande y cerrado en el que se está haciendo muy poco más. Esta situación no ocurre muy a menudo; por lo general, comprobará si hay un valor nulo y luego hará algo relativamente caro con esa referencia.

No hay ninguna situación en la que un bloqueo o falla sea algo bueno. Siempre es mejor "reducir la velocidad de su aplicación" con chequeos nulos que estrellarse y perder los datos de su cliente.

Así que no optimice prematuramente su código. Escríbalo bien, para que sea fácil de mantener y sólido, luego perfil para ver dónde están los cuellos de botella. He estado programando durante 28 años, siendo muy liberal con las comprobaciones nulas, y tengo nunca encontré que una verificación nula fue la causa de un problema de rendimiento. Por lo general, es algo como hacer un montón de trabajo innecesario en un bucle, utilizando un algoritmo O (n^3) donde es posible un enfoque O (n^2), no se pueden caché valores caros para calcular, etc.