Events - Handler vs direct access? Why?

Question

SAMPLE CODE:

public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(String propertyName) 
{ 
    PropertyChangedEventHandler handler = PropertyChanged; 
    if (handler != null) 
    {
        handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

VS:

public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(String propertyName) 
{ 
    if (PropertyChanged!= null) 
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

Why is it that I always see people creating assigning PropertyChanged to a "handler" instead of just using it?

Answer 1

If you do it the simpler way, and a different thread removes the last handler from the event just inside your if, you'll get a null reference. (delegates are immutable)

By making a handler temporary, you prevent this, since you only check the field once.

If the event will never be unsubscribed to from multiple threads, you don't need the temporary.

Answer 2

Did you ever actually see this happen?

Sure, this takes a fraction of second to bomb on my machine after starting it:

using System;
using System.Threading;

class Program {
    static void Main(string[] args) {
        EventHandler anEvent = null;
        var t1 = ThreadPool.QueueUserWorkItem((w) => {
            for (; ; ) {
                anEvent += Test;
                anEvent -= Test;
            }
        });
        var t2 = ThreadPool.QueueUserWorkItem((w) => {
            for (; ; ) {
                if (anEvent != null) anEvent(null, null);
            }
        });
        Console.ReadLine();
    }

    static void Test(object sender, EventArgs e) { }
}

It is a quick crash due to the relentlessly quick looping. In a real app this takes anywhere between a day and a year to crash. The odds that you'll catch it while debugging your code are very slim. If it does happen you'll go, "wtf? Let's try again" and not get it again.