C# Delegate Shortcut – No more null testing on events for subscribers

kick it on DotNetKicks.com

This is fairly well known but I realized I hadn’t seen it blogged about (sorry if already covered).

Your likely used to doing this:

 public event EventHandler<AnimationImageEventArgs>
                AnimationImageClicked;
 private void OnClick(object sender, AnimationImageEventArgs e)
{
    if (AnimationImageClicked != null)
          AnimationImageClicked(sender, e);
}

No need for that null check. I for one tend to forget them in the bowels of my teams code. What is better then eliminating the issue!

This is a way to ‘always have one subscriber’ which you can consider a sort of ‘null object’ pattern implementation for delegates. Checking for null just sucks and I love this kind of ubiquitous removal of it.

The first person I saw doing this was Juval Lowy, the master craftsman for basically all things .NET but known recently for utter mastery of WCF in his books and at his firm IDesign. Highly recommend all his writing, code samples and thoughts.

public event EventHandler<AnimationImageEventArgs>
            AnimationImageClicked = delegate { };
private void OnClick(object sender, AnimationImageEventArgs e)
{
           AnimationImageClicked(sender, e);
}

Damon

Digg This

2 Comments

  1. Nice tips!

    Thanks !

  2. This is especially nice as I see sometimes people have special logic ‘if the event handler is not null’

    This is bad. The observer pattern (which is what events are) is about never having to care if you have 0, 1 or more subscribers. If you hace logic that cares, it is broken almost certainly…..

    Why? Because ‘you will never know’ in a real framework environment if/how many/etc. about who is listening at any given moment to your events. You always have to assume there could be nobody.

    One interest caveat: Do you have unrecoverable cases where you simply cannot continue if there are no subscribers to any given event?

    For this case it is dangerous ground. I would encourage a rethink of the design. For example, (and this happens far too often in Silverlight due to the async nature of it) I have a few background activities which are retrieving the initialization data for my app. I have no idea when this will all be done exactly so I have a method of raising an event when ‘the bare minimum’ is done.

    I AM the one subscribing to the framework events (the WebClient download string/stream callbacks for example) not my ‘client’ who is waiting on the result.

    So I expost an event called ‘InitializationComplete’. I introduced a regression and it is not subscribed.

    So I sink MY events and get the result. The data is there and I raise my event (blissfully not knowing if anyone is on the other end).

    So what happens?????

    In my opinion there would need (in any case) to be a reasonable timeout defined. This is on ‘my client’s’ code. So when it is done with all it needs to do and is basically now waiting for this event, it should not be forever.

    In this case it will timeout. HOWEVER, it is easier to debug and you immediately know the issue if that null check is performed..

    Hmm…. I guess this is one for ‘personal preference’? Thoughts?

    Damon


Post a Comment