73

I recall reading, on multiple occasions and in multiple locations, that when firing the typical event:

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

e should be EventArgs.Empty if there are no interesting event args, not null.

I've followed the guidance in my code, but I realized that I'm not clear on why that's the preferred technique. Why does the stated contract prefer EventArgs.Empty over null?

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
Greg D
  • 43,259
  • 14
  • 84
  • 117

6 Answers6

37

I believe the reasoning behind the NOT NULL is that when passed as a parameter, it is not expected for the method to need to potentially handle a null reference exception.

If you pass null, and the method tries to do something with e it will get a null reference exception, with EventArgs.Empty it will not.

Mitchel Sellers
  • 62,228
  • 14
  • 110
  • 173
  • In what situations would you use a similar technique in your own code? – Greg D Oct 09 '08 at 19:49
  • 8
    If one method might pass event information and another might not. I can still call e.ToString() regardless, but one might pass a custom type and the other passes EventArgs.Empty – Mitchel Sellers Oct 09 '08 at 20:07
  • 5
    Greg, the whole point here is that the event handler is *not* your code. You want safety first here because you are defining and raising the event, and somebody else will write the event handler. – Concrete Gannet Apr 16 '13 at 06:10
  • 4
    There are conventions and norms, if not guarantees, around events. One is the EventArgs should *never* be null and the handler should not have to check for it. – Concrete Gannet Apr 16 '13 at 06:18
28

EventArgs.Empty is an instance of the Null object pattern.

Basically, having an object representing "no value" to avoid checking for null when using it.

Martin Konicek
  • 39,126
  • 20
  • 90
  • 98
8

I believe EventArgs.Empty is used to maintain the convention of passing an argument with an event, even if none are needed.

Mitchel Sellers posted the other half of my reason halfway through my post: it prevents a null reference exception should a method try and do something with that argument (besides check if it is null).

EventArgs.Empty basically does the work of a globally defined Event Argument with no additional information.

To give a similar example of maintaining a convention, our team uses string.Empty to initialize a string because otherwise different coders might use newString = ""; or newString = " "; or newString = null;, all of which may produce different results for different check conditions.

A (slightly pedantic) reason to use EventArgs.Empty vs new EventArgs() is that the former does not initialize a new EventArgs, saving a slight amount of memory.

Stephen Kennedy
  • 20,585
  • 22
  • 95
  • 108
ForCripeSake
  • 438
  • 1
  • 6
  • 11
  • 2
    The "slight amount of memory" might be significant for an event that is raised many times, like a MouseMove event. – Concrete Gannet Apr 16 '13 at 06:19
  • 1
    Doesn't EventArgs.Empty return an reference to an new instance of EventArgs? So where does the memory saving come from? –  Dec 15 '18 at 15:33
2

If you're using a general-purpose method which has the EventHandler signature that's called from any event handler and is passed both the object sender and EventArgs e, it can call e.ToString(), e.g., for logging events, without worrying about a null pointer exception.

Mark Cidade
  • 98,437
  • 31
  • 224
  • 236
0

I used long time "new EventArgs()" instead of "EventArgs.Empty"... I think the important is to pass something that will not cause an Null exception.

Patrick Desjardins
  • 136,852
  • 88
  • 292
  • 341
  • 5
    EventArgs.Empty isn't null, it's a static variable initialized with "new EventArgs()". It means you don't end up wasting resources initializing what is effectively a placeholder object with no varying value. – ICR Oct 10 '08 at 12:21
  • 3
    If there is no meaningful data in the EventArgs, don't instantiate one. EventArgs.Empty will do the job without the overhead of creating a useless object which will only be garbage collected. – Concrete Gannet Apr 16 '13 at 06:22
  • I agree. Using new EventArgs() makes the intent less clear to the next programmer who comes along, and it's slightly wasteful. – Jon Coombs Mar 21 '14 at 23:17
0

from Albahari book: "in order to avoid unnecessarily instantiating an instance of EventArgs."

Bobak_KS
  • 556
  • 3
  • 10