Pourquoi utiliser EventArgs.Empty au lieu de null?

Question

Je me souviens avoir lu, à plusieurs reprises et à plusieurs endroits, que lors du déclenchement de l'événement type:

protected virtual OnSomethingHappened()
{
    this.SomethingHappened(this, EventArgs.Empty);
}

e devrait être EventArgs.Empty s'il n'y a pas d'argument d'événement intéressant, pas null.

J'ai suivi les instructions de mon code, mais je me suis rendu compte que je ne comprenais pas pourquoi c'était la technique préférée. Pourquoi le contrat indiqué préfère-t-il EventArgs.Empty à null?

Answer 1

Je crois que le raisonnement sous-jacent à NOT NULL est que, une fois passé en tant que paramètre, il n'est pas attendu que la méthode doive potentiellement gérer une exception de référence null.

Si vous passez null et que la méthode essaie de faire quelque chose avec e, elle obtiendra une exception de référence null, avec EventArgs.Empty ce ne sera pas le cas.

Answer 2

EventArgs.Empty est une instance du Modèle d'objet nul .

En gros, avoir un objet représentant "aucune valeur". pour éviter de rechercher la valeur null lors de son utilisation.

Answer 3

Je crois que EventArgs.Empty est utilisé pour conserver la convention de passage d'un argument avec un événement, même si aucun n'est nécessaire.

Mitchel Sellers a posté l’autre moitié de ma raison au milieu de mon message: cela empêche une exception de référence nulle si une méthode essaye de faire quelque chose avec cet argument (en plus de vérifier si elle est nulle).

EventArgs.Empty effectue essentiellement le travail d'un argument d'événement défini globalement, sans aucune information supplémentaire.

Pour donner un exemple similaire de gestion d'une convention, notre équipe utilise string.Empty pour initialiser une chaîne car sinon, des codeurs différents pourraient utiliser newString = " ;; ou newString = " " ;; ou newString = null; , qui peuvent tous produire des résultats différents pour des conditions de contrôle différentes.

Une raison (légèrement pédante) d'utiliser EventArgs.Empty et new EventArgs () indique que l'ancien ne initialise pas un nouveau EventArgs . , en économisant une petite quantité de mémoire.

Answer 4

Si vous utilisez une méthode générique qui a la signature EventHandler appelée depuis n'importe quel gestionnaire d'événements et transmet à la fois l'expéditeur de l'objet et EventArgs e , il peut appeler e.ToString () , par exemple, pour consigner des événements, sans se soucier d'une exception de pointeur null.

Answer 5

J'ai utilisé longtemps "new EventArgs ()". Au lieu de "EventArgs.Empty" ... je pense que l'important est de transmettre quelque chose qui ne causera pas d'exception Null.

Answer 6

du livre Albahari: "afin d'éviter d'instancier inutilement une instance de EventArgs."