Почему C# требует, чтобы Вы выписали пустой чек каждый раз, когда Вы запускаете событие?

Не знаю, зачем это делается, но есть вариант шаблона нулевого объекта специально для делегатов:

private event EventHandler Foo = (sender, args) => {};

Таким образом, вы можете свободно вызвать Foo , никогда не проверяя null .

Вам нужно подумать о том, какой код потребуется, если настройка оборудования, чтобы поднять событие в первую очередь, будет дорогой (как SystemEvents) или если подготовка аргументов события будет дорогой (как событие Paint).

Стиль обработки событий в Visual Basic не позволяет вам отложить расходы на поддержку такого события. Вы не можете переопределить аксессоры добавления/удаления, чтобы отложить дорогостоящую установку. И вы не можете обнаружить, что может не быть подписано ни одного обработчика событий, так что сжигание циклов для подготовки аргументов события - пустая трата времени.

В C# это не проблема. Классический компромисс между удобством и контролем.

Причина в том, что C # дает вам больше контроля. В C # вам не нужно выполнять проверку null , если вы этого захотите. В следующем коде MyEvent никогда не может быть нулевым , так зачем вообще проверять?

public class EventTest
{
  private event EventHandler MyEvent = delegate { Console.WriteLine("Hello World"); }

  public void Test()
  {
    MyEvent(this, new EventArgs());
  }
}

Потому что RaiseEvent несет некоторые накладные расходы.

Всегда есть компромисс между контролем и простотой использования.

• VB.Net: простота использования,
• C#: больше контроля, как в VB
• C++: еще больше контроля, меньше руководства, легче выстрелить себе в ногу

Методы расширения предоставляют очень интересный способ обойти это. Рассмотрим следующий код:

static public class Extensions
{
    public static void Raise(this EventHandler handler, object sender)
    {
        Raise(handler, sender, EventArgs.Empty);
    }

    public static void Raise(this EventHandler handler, object sender, EventArgs args)
    {
        if (handler != null) handler(sender, args);
    }

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

Теперь вы можете просто сделать это:

class Test
{
    public event EventHandler SomeEvent;

    public void DoSomething()
    {
        SomeEvent.Raise(this);
    }
}

Однако, как уже упоминалось, вы должны знать о возможном состоянии гонки в многопоточных сценариях.

мы обычно работаем над этим, объявляя наши события следующим образом:

public event EventHandler<FooEventArgs> Foo = delegate { };

это дает два преимущества. Во-первых, у нас нет проверки на null. Во-вторых, мы избегаем проблемы с критическим разделом, которая присутствует повсеместно при типичном запуске события:

// old, busted code that happens to work most of the time since
// a lot of code never unsubscribes from events
protected virtual void OnFoo(FooEventArgs e)
{
    // two threads, first checks for null and succeeds and enters
    if (Foo != null) {
        // second thread removes event handler now, leaving Foo = null
        // first thread resumes and crashes.
        Foo(this, e);
    }
}

// proper thread-safe code
protected virtual void OnFoo(FooEventArgs e)
{
     EventHandler<FooEventArgs> handler = Foo;
     if (handler != null)
         handler(this, e);
}

Но с автоматической инициализацией Foo пустым делегатом никогда не требуется никаких проверок, и код автоматически становится потокобезопасным и проще читать для загрузки:

protected virtual void OnFoo(FooEventArgs e)
{
    Foo(this, e); // always good
}

С извинениями Пэту Морите из «Каратэ Кид»: «Лучший способ избежать null - это не иметь его».

Что касается того, почему, C # не балует вас так сильно, как VB. Хотя ключевое слово event скрывает большую часть деталей реализации делегатов многоадресной рассылки , оно дает вам более точный контроль, чем VB.