Why do events not offer 3 accessor methods?

Question

When implementing events, one can provide code for add and remove a event handler. However, events can be accessed in three ways:

MyEvent += Handler;                // add accessor
MyEvent -= Handler;                // remove accessor
MyEvent(this, EventArgs.Empty);    // not supported by an accessor

Wouldn't it be obvious to have another accessor called invoke that is responsible for that? My thoughts are:

class BaseClass
{
  public virtual event EventHandler MyEvent { add; remove; protected invoke; }
}

class DerivedClass : BaseClass
{
  public override event EventHandler MyEvent
  {
    invoke
    {
      // new code before event
      base.MyEvent(this, ...);
      // new code after event
    }
  }
}

I know of the old-style pattern, which is to implement an OnMyEvent(...) method. But there two important drawback with this approach:

1. Event code is scattered -> less organized code base
2. You can't refactor the event easily (e.g., rename it)

Edit: Obviously the compiler team already designed for this feature (See GetRaiseMethod()).

Answer 1

This is on purpose, so that you don't invoke events that you don't "own".

Edit (to address you edit): even in an inherited class it is unclear whether you should always be able to invoke it. Usually yes, and therefore the common pattern is well set out:

• Define an event (not prefixed with On)
• Create a protected virtual method with the same name but prefixed with On, which accepts the appropriate EventArgs and just does the null check and the invocation.
• Always raise the event through the virtual method

This pattern allows greater flexibility; one can change or omit events or do post-event processing by inheriting the method. If no method exist, the event invocation is private.