In C# why can't I pass another class' EventHandler reference and how can I get around it?

Question

If I have ClassA that has a public event, SomeEvent, and ClassC that has method, addListener, that accepts an EventHandler reference, why can\'t ClassB have a line that says

Answer 1

The event keyword creates an accessor for a private delegate object. The exact same thing a property does, it restricts access to a private field. Your code snippet fails with a similar kind of error when you use a property instead of an event:

  class ClassA {
    public int Property { get; set; }
  }
  class ClassB {
    public ClassB() {
      ClassA a = new ClassA();
      ClassC c = new ClassC();
      c.setValue(ref a.Property);   // CS0206
    }
  }
  class ClassC {
    public void setValue(ref int value) {
      value = 42;
    }
  }

It is easier to see now, there is no way for the compiler to ensure that the setValue() method uses the property setter. Nor could it know that the "value" argument is a property with a setter or a plain field.

It is less clear for an event because there is so much syntax sugar at work. This declaration

public event EventHandler SomeEvent;

actually generates this code:

private EventHandler _SomeEvent;
public event SomeEvent {
  add    { _SomeEvent += new EventHandler(value); }
  remove { _SomeEvent -= new EventHandler(value); }
}

The add and remove accessors are equivalent to the get and set accessors of a property, they prevent code from messing with the private _SomeEvent field. By convention, the add accessor is invoked when you use +=, remove is invoked with -=. Compare this with the earlier example I gave for a property. Same problem, you can't use the ref keyword and ClassC.addListener() would have no way to know that the handler is actually an event instead of a delegate object. If the compiler would pass _SomeEvent instead, the point of using the accessors is lost.

You can restructure the code to solve this problem:

  class ClassC {
    public EventHandler getListener() {
      return new EventHandler(onEvent);
    }
    private void onEvent(object sender, EventArgs e) { }
  }
...
      a.SomeEvent += c.getListener();

---

One final note: the symmetry between an event and a property is a bit lost, the C# compiler automatically generates the add/remove accessors if you don't write them explicitly. It doesn't do this for a property. It would have made automatic properties a lot easier:

property int Property;

But that would have required adding a new keyword to the language, something the C# team really dislikes. Other languages like VB.NET and C++/CLI do have that keyword.

Answer 2

How can I get around it while staying reasonably close to my structure?

Use a.SomeEvent += handler instead.

Why does this restriction exist?

See Marc Gravell's answer.

Answer 3

Outside of the class, you only have access to the add and remove accessors - that is the point of an event you can neither see other subscribers, nor change them (for example, setting the event to null). It would be better to handle the event normally, and cause whatever consequences you need.

Imagine you could do what you suggest. For example, suppose you subscribe to a button click, and some other code uses that info to hook you into a "tick" event - you're code isn't going to work as it expected to = bug.

To make that explict; an event isn't an EventHandler, in the same way that a property isn't an int - the event/property defines accessor methods.

Re your scenario, either make OnEvent public and use a.SomeEvent += c.OnEvent;, or have some similar method and use an anon-method:

a.SomeEvent += delegate { c.DoSomethingCool(); };