Comprobación de Null en el Constructor

Question

Estoy tratando de descubrir las mejores prácticas para el código reutilizable que se depura fácilmente. Me encontré con una práctica común entre los desarrolladores que aún no entiendo del todo.

public MyConstructor(Object myObject) 
{ 
    if (myObject == null) 
     throw new ArgumentNullException("myObject is null."); 
    _myObject = myObject; 
} 

Parece casi innecesario hacer esta comprobación. Pero creo que es porque no entiendo completamente cuáles son los beneficios de hacer este control. Parece que una excepción de referencia nula sería lanzada de todos modos? Probablemente estoy equivocado, realmente me gustaría escuchar algunas ideas al respecto.

Gracias.

Answer 1

Para el compilador, null es un argumento de constructor legítimo.

Su clase podría ser capaz de manejar un valor nulo para myObject. Pero si no puede - si su clase se romperá cuando myObject es nulo - entonces el check in en el constructor le permite fail fast.

Answer 2

El compilador no tiene idea del valor de un objeto, por lo que debe comprobarlo en tiempo de ejecución para asegurarse de que no se invoque con un valor nulo.

También depende de su solución particular. No necesita lanzar la excepción, solo la lanzaría si no puede tener ese valor como nulo, y si es nulo, ese es un caso excepcional.

Answer 3

Creo que no es posible decir en general si es necesario o no verificar el nulo. Más bien depende de si puede vivir con variables de valor nulo o no. Nulo no es per se un mal estado. Es posible que tenga situaciones en las que se permite que una variable sea nula y otra donde no lo sea.

Pregúntese si tiene sentido permitir valores nulos o no y diseñe el constructor en consecuencia.

Answer 4

Pasar un objeto null es perfectamente legal en muchos casos - para esta clase el implementador quiere asegurarse de que no puede crear una instancia de la clase sin pasar una instancia válida de Object, por lo que no debe haber controles posteriores en - es una buena práctica para asegurar esto tan pronto como sea posible, que estaría en el constructor.

Answer 5

Necesita comprobar explícitamente null porque el compilador no lo sabe, pero también porque null puede ser un argumento válido.

Answer 6

La ventaja es que la excepción se producirá en el momento de la construcción del objeto, por lo que puede rastrear fácilmente qué parte del código es la culpable. Si el código requiere no nulo valor myobject y que no validan en el constructor, el NullReferenceException serán arrojados al utilizar myObject_ y tendrá que rastrear manualmente para ver quién envió ese valor nulo en.

Answer 7

Podría implementar un método de extensión simple ThrowIfNull para reducir el código que escribe cada vez. Jon Skeet lo cubrió en su blog y en el artículo SO here.

Answer 8

si bajo 4.0 se puede hacer lo siguiente:

public ctor(IEnjection ninjaWeapon) 
{ 
    Contract.Requires<ArgumentNullException>(ninjaWeapon != null); 
    this.deadlyWeaponary.Add(ninjaWeapon); 
} 

si en virtud de una versión más antigua, hacer referencia a la Microsoft.Contract a hacer lo mismo.