Чи є недолік додавання анонімного порожнього делегата в оголошенні події?

Я бачив кілька згадувань про цю ідіому (в тому числі про SO ):

// Deliberately empty subscriber
public event EventHandler AskQuestion = delegate {};

Переваги зрозумілі - це дозволяє уникнути необхідності перевіряти наявність нуля перед тим, як підняти подію.

Однак я хочу зрозуміти, чи є якісь мінуси. Наприклад, чи є це щось широко поширене і є достатньо прозорим, щоб не викликати головного болю в обслуговуванні? Чи є якийсь помітний показник продуктивності дзвінка абонента порожньої події?

Єдиний мінус - дуже незначне покарання за продуктивність, оскільки ви викликаєте зайвого порожнього делегата. Крім цього, не передбачено штрафу за обслуговування або інших недоліків.

Замість того, щоб викликати накладні витрати на продуктивність, чому б не використати метод розширення для полегшення обох проблем:

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

Одного разу визначившись, вам більше ніколи не доведеться робити ще одну перевірку нульової події:

// Works, even for null events.
MyButtonClick.Raise(this, EventArgs.Empty);

Для систем, які інтенсивно використовують події та є критично важливими для продуктивності , ви точно захочете принаймні подумати про те, щоб цього не робити. Вартість підняття події з порожнім делегатом приблизно вдвічі перевищує вартість підняття події за допомогою нульової перевірки.

Ось кілька цифр, що виконують тести на моїй машині:

For 50000000 iterations . . .
No null check (empty delegate attached): 530ms
With null check (no delegates attached): 249ms
With null check (with delegate attached): 452ms

І ось код, за яким я отримував ці цифри:

using System;
using System.Diagnostics;

namespace ConsoleApplication1
{
    class Program
    {
        public event EventHandler<EventArgs> EventWithDelegate = delegate { };
        public event EventHandler<EventArgs> EventWithoutDelegate;

        static void Main(string[] args)
        {
            //warm up
            new Program().DoTimings(false);
            //do it for real
            new Program().DoTimings(true);

            Console.WriteLine("Done");
            Console.ReadKey();
        }

        private void DoTimings(bool output)
        {
            const int iterations = 50000000;

            if (output)
            {
                Console.WriteLine("For {0} iterations . . .", iterations);
            }

            //with anonymous delegate attached to avoid null checks
            var stopWatch = Stopwatch.StartNew();

            for (var i = 0; i < iterations; ++i)
            {
                RaiseWithAnonDelegate();
            }

            stopWatch.Stop();

            if (output)
            {
                Console.WriteLine("No null check (empty delegate attached): {0}ms", stopWatch.ElapsedMilliseconds);
            }


            //without any delegates attached (null check required)
            stopWatch = Stopwatch.StartNew();

            for (var i = 0; i < iterations; ++i)
            {
                RaiseWithoutAnonDelegate();
            }

            stopWatch.Stop();

            if (output)
            {
                Console.WriteLine("With null check (no delegates attached): {0}ms", stopWatch.ElapsedMilliseconds);
            }


            //attach delegate
            EventWithoutDelegate += delegate { };


            //with delegate attached (null check still performed)
            stopWatch = Stopwatch.StartNew();

            for (var i = 0; i < iterations; ++i)
            {
                RaiseWithoutAnonDelegate();
            }

            stopWatch.Stop();

            if (output)
            {
                Console.WriteLine("With null check (with delegate attached): {0}ms", stopWatch.ElapsedMilliseconds);
            }
        }

        private void RaiseWithAnonDelegate()
        {
            EventWithDelegate(this, EventArgs.Empty);
        }

        private void RaiseWithoutAnonDelegate()
        {
            var handler = EventWithoutDelegate;

            if (handler != null)
            {
                handler(this, EventArgs.Empty);
            }
        }
    }
}

Якщо ви робите це в / lot /, вам може знадобитися один, статичний / спільний порожній делегат, який ви використовуєте повторно, просто для зменшення обсягу екземплярів делегатів. Зауважте, що компілятор у будь-якому випадку кешує цей делегат на подію (у статичному полі), тому це лише один екземпляр делегата на визначення події, тому це не величезна економія - але, можливо, варто.

Звичайно, поле для кожного екземпляра в кожному класі все одно займе однаковий простір.

тобто

internal static class Foo
{
    internal static readonly EventHandler EmptyEvent = delegate { };
}
public class Bar
{
    public event EventHandler SomeEvent = Foo.EmptyEvent;
}

Окрім цього, це здається чудовим.

Немає значущого покарання за виконання, за винятком, можливо, деяких екстремальних ситуацій.

Однак зауважте, що цей трюк стає менш актуальним у C # 6.0, оскільки мова надає альтернативний синтаксис виклику делегатів, який може бути нульовим:

delegateThatCouldBeNull?.Invoke(this, value);

Вище, нульовий умовний оператор ?.поєднує перевірку нуля з умовним викликом.

Я розумію, що порожній делегат є потокобезпечним, тоді як перевірка нуля - ні.

Я б сказав, що це трохи небезпечна конструкція, тому що вона спокушає вас зробити щось на зразок:

MyEvent(this, EventArgs.Empty);

Якщо клієнт видає виняток, сервер йде з ним.

Тоді, можливо, ви робите:

try
{
  MyEvent(this, EventArgs.Empty);
}
catch
{
}

Але якщо у вас кілька абонентів, і один абонент видає виняток, що відбувається з іншими абонентами?

З цією метою я використовував деякі статичні допоміжні методи, які виконують нульову перевірку та ковтають будь-які винятки з боку абонента (це від idesign).

// Usage
EventHelper.Fire(MyEvent, this, EventArgs.Empty);


public static void Fire(EventHandler del, object sender, EventArgs e)
{
    UnsafeFire(del, sender, e);
}
private static void UnsafeFire(Delegate del, params object[] args)
{
    if (del == null)
    {
        return;
    }
    Delegate[] delegates = del.GetInvocationList();

    foreach (Delegate sink in delegates)
    {
        try
        {
            sink.DynamicInvoke(args);
        }
        catch
        { }
    }
}

Замість підходу "порожній делегат" можна визначити простий метод розширення для інкапсуляції звичайного методу перевірки обробника подій на нуль. Це описано тут і тут .

Відповідь на це запитання поки що пропущено: небезпечно уникати перевірки нульового значення .

public class X
{
    public delegate void MyDelegate();
    public MyDelegate MyFunnyCallback = delegate() { }

    public void DoSomething()
    {
        MyFunnyCallback();
    }
}


X x = new X();

x.MyFunnyCallback = delegate() { Console.WriteLine("Howdie"); }

x.DoSomething(); // works fine

// .. re-init x
x.MyFunnyCallback = null;

// .. continue
x.DoSomething(); // crashes with an exception

Річ у тім, що ви ніколи не знаєте, хто яким способом використовуватиме ваш код. Ви ніколи не знаєте, чи через кілька років під час виправлення помилки вашого коду подія / обробник встановлюється як нуль.

Завжди пишіть перевірку if.

Сподіваюся, що допомагає;)

ps: Дякую за розрахунок продуктивності.

pps: відредаговано його від випадку події до прикладу зворотного виклику. Дякую за відгук ... Я "закодував" приклад без Visual Studio і пристосував приклад, який я мав на увазі, до події. Вибачте за непорозуміння.

ppps: Не знаю, чи все-таки це відповідає нитці ... але я думаю, що це важливий принцип. Будь ласка, перевірте ще один потік стеку