在事件声明中添加匿名空委托有缺点吗？

Question

我见过一些关于这个习语的提及（包括on SO）：

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

好处是clear - 它避免了在引发事件之前检查 null 的需要。

但是，我很想知道是否有任何缺点。例如，它是否被广泛使用并且足够透明，不会导致维护麻烦？ 空事件订阅者调用是否会对性能造成明显影响？

Answer 1

为什么不使用扩展方法来缓解这两个问题，而不是引起性能开销：

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);

Answer 2

对于大量使用事件并且对性能至关重要的系统，您肯定至少考虑不这样做。 使用空委托引发事件的成本大约是首先使用空检查引发事件的成本的两倍。

以下是在我的机器上运行基准测试的一些数据：

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);
            }
        }
    }
}

Answer 3

唯一的缺点是，当您调用额外的空委托时，性能会受到非常轻微的影响。 除此之外，没有维护惩罚或其他缺点。

Answer 4

如果您经常这样做，您可能希望有一个可重复使用的单个静态/共享空委托，只是为了减少委托实例的数量。 请注意，编译器无论如何都会缓存每个事件的此委托（在静态字段中），因此每个事件定义只有一个委托实例，因此这不是一个巨大的节省 - 但也许是值得的。

当然，每个类中的每个实例字段仍将占用相同的空间。

即

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

除此之外，似乎还不错。

Answer 5

除了可能的某些极端情况之外，没有什么有意义的性能损失可讨论。

但请注意，此技巧在 C# 6.0 中变得不太相关，因为该语言提供了一种替代语法来调用可能为 null 的委托：

delegateThatCouldBeNull?.Invoke(this, value);

上面，null 条件运算符 ?. 将 null 检查与条件调用结合在一起。

Answer 6

据我了解，空委托是线程安全的，而空检查则不是。

Answer 7

我想说这是一个有点危险的构造，因为它诱惑你做类似的事情：

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
        { }
    }
}

Answer 8

除了“空委托”方法之外，我们还可以定义一种简单的扩展方法来封装检查事件处理程序是否为 null 的传统方法。 此处和此处。

Answer 9

到目前为止，这个问题的答案被遗漏了：避免检查 null 值是危险的。

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：不知道它是否仍然适合线程......但我认为这是一个重要的原则。 另请检查 stackflow 的另一个线程