Lancer ArgumentNullException

Question

Supposons que j'ai une méthode qui prend un objet d'une certaine sorte, comme un argument. Maintenant dire que si cette méthode est adoptée un argument null, c'est une erreur fatale et une exception doit être levée. Est-il utile pour moi de code quelque chose comme ceci (en gardant à l'esprit que c'est un exemple trivial):

void someMethod(SomeClass x)
{
    if (x == null){
        throw new ArgumentNullException("someMethod received a null argument!");
    }

    x.doSomething();
}

Ou est il sans danger pour moi de simplement compter sur elle en jetant NullException lorsqu'il appelle x.doSomething()?

Deuxièmement, supposons que someMethod est un constructeur et x ne sera pas utilisé jusqu'à ce qu'une autre méthode est appelée. Dois-je lancer l'exception immédiatement ou attendre jusqu'à ce que x est nécessaire et jeter l'exception, alors?

Answer 1

Je préfère le ArgumentNull exception sur le NullReference exception qui ne vérifiant pas l'argument de fournir. En général, ma préférence est de toujours vérifier la nullité avant d'essayer d'appeler une méthode sur un potentiellement l'objet null.

Si la méthode est un constructeur, puis il dépendra d'un couple de différents facteurs: est-il aussi un setter de la propriété et quelle est la probabilité que l'objet sera effectivement utilisée. Si il y a un public setter, puis de ne pas fournir une instance valide via le constructeur serait raisonnable et ne devrait pas aboutir à une exception.

Si il n'y a pas de setter et il est possible d'utiliser l'objet contenant sans référence à l'injection de l'objet, vous pouvez reporter la vérification/exception jusqu'à ce que son utilisation est tentée. Je pense que le cas général, même si, serait injecté objet est essentielle pour le fonctionnement de l'instance et donc une ArgumentNull exception est tout à fait raisonnable puisque l'instance ne peut pas fonctionner sans elle.

Answer 2

Je suis toujours la pratique de l'échec rapide. Si votre méthode dépend de X et que vous comprenez que X peut être passé à NULL, vérifiez-le et générez l'exception immédiatement au lieu de prolonger le point d'échec.

Answer 3

Je préfère l'exception explicite, pour ces raisons:

• Si la méthode a plus d'un argument SomeClass, vous avez la possibilité de dire de quel argument il s'agit (tout le reste est disponible dans la pile d'appels).
• Que faire si vous faites quelque chose qui peut avoir un effet secondaire avant de référencer x?

Answer 4

Je suis d'accord avec l'idée de l'échec rapide cependant, il est sage de savoir pourquoi à défaut de rapide est pratique. Considérons cet exemple:

void someMethod(SomeClass x)
{   	
    x.Property.doSomething();
}

Si vous comptez sur l' NullReferenceException pour vous dire que quelque chose n'allait pas, comment allez-vous savoir ce qui est null? La trace de la pile ne fera que vous donner un numéro de ligne, pas de référence qui a été nulle. Dans cet exemple, x ou x.Property pourrait à la fois avoir été nulle et sans faillir rapide agressive de la vérification à l'avance, vous ne saurez pas qui c'est.

Answer 5

Je préférerais aussi le paramètre check avec l'exception explicite ArgumentNullException.

En regardant les métadonnées:

  //
    // Summary:
    //     Initializes a new instance of the System.ArgumentNullException class with
    //     the name of the parameter that causes this exception.
    //
    // Parameters:
    //   paramName:
    //     The name of the parameter that caused the exception.
    public ArgumentNullException(string paramName);
 

Vous pouvez voir que la chaîne doit être le nom du paramètre, null, et donner ainsi au développeur un indice sur ce qui ne va pas.