Does an event need to have at least one handler?

Question

Why event needs to have at least one handler?

I created custom event for my Control and somewhere inside of code of my control, I call this event:

this.MyCustomEvent(this, someArgs);

it throws a NullReferenceException if there is no handler subscribed to it.

When I added a single handler in control's constructor, everything works fine:

this.MyCustomEvent += myCutomEventHandler;

void myCustomEventHandler(object sender, EventArgs e)
{ /* do nothing */ }

Is this normal or maybe I'm doing something wrong? Shouldn't it check automatically if there are any handlers subscribed? It's a little dumb, IMHO.

Answer 1

This is the normal behavior. To avoid this always test if there's an event subscriber before calling it:

if (MyCustomEvent != null)
{
    MyCustomEvent(this, someArgs);
}

Answer 2

Yes, you need to check for null. In fact, there's a right way to do it:

var myEvent = MyCustomEvent;
if (myEvent != null)
    myEvent(this, someArgs);

This is the official right way because it avoids a possible race condition when the event is changed after the null check but before the call.

Answer 3

An event at the bottom is MulticastDelegate, which is null if there is no method in the invocation list. Usually, you use a RaiseEvent() method to call an event, the pattern looks like the following:

public void RaiseEvent()
{
  var handler = MyEvent;
  if(handler != null)
    handler(this, new EventArgs());
}

As you assign the event to a variable, it is threadsafe. You can miss a removed or added method though, which was added between the atomic operations (assignment -> null check -> invocation).

Answer 4

Note that delegates are reference types, and their default value is null.

The solution proposed by others, i.e. to check for null before firing the event, is not thread-safe because listeners may unsubscribe from the event between the null check and the firing of the event. I have seen solutions that involve copying the delegate to a local variable, and checking it for null before firing, such as

EventHandler myCustomEventCopy = MyCustomEvent;

if (myCustomEventCopy != null)
{
    myCustomEventCopy (this, someArgs);
}

But this has a race-condition, i.e. handlers may fire even after they have unsubscribed from the event, which may corrupt the state of the application.

One solution that handles both problems is to initialize events to a blank handler, e.g.

public event EventHandler MyCustomEvent = delegate { };

and then fire them off without any checks, e.g.

MyCustomEvent(this, someArgs);

Edit: As others have pointed out, this is a complex issue.

http://blogs.msdn.com/b/ericlippert/archive/2009/04/29/events-and-races.aspx

Lippert points out that completely removing the "handler is fired after deregistration" problem requires that the handlers themselves are written in a robust manner.

Answer 5

This is normal behaviour. The conventional pattern for throwing an event in .NET is to have a method called OnMyCustomEvent that you use to throw the event, like so:

    protected void OnMyCustomEvent(MyCustomEventArgs e)
    {
        EventHandler<MyCustomEventArgs> threadSafeCopy = MyCustomEvent;
        if (threadSafeCopy != null)
            threadSafeCopy(this, e);
    }

    public event EventHandler<MyCustomEventArgs> MyCustomEvent;

Then from your code, you would call this.OnMyCustomEvent(someArgs) instead.

Answer 6

I recommend you to have an extremely useful extension method:

public static void Raise<T>(this EventHandler<T> eventHandler, object sender, T e) where T : EventArgs
{
    if (eventHandler != null)
    {
         eventHandler(sender, e);
     }
}

which will do the check for you.

Usage:

MyCustomEvent.Raise(this, EventArgs.Empty);