You've been kicked (a good thing) - Trackback from DotNetKicks.com

Brilliant!  Reminds me of the null object pattern.  I haven't seen this before either but I think I'll incorporate it in my mental toolbox (once I get out of @%^# 1.1 land, that is!)

You're not alone. I've never seen this, either. That really *does* simplify things!

How would this work with VB? I would assume you would have the following:

Public Event Updated As EventHandler = AddressOf SomeAnonymousMeth

That does not work. I'm not fluent with C# so maybe you can offer some help. Thanks!

It's like passing a zero length array istead of a null pointer.

Actually I think there should be some compiler support for calling in on events that could be nullpointers, in which case the call would be ommited.

I propose this syntax:

--

public event MySpecialThingHappened;

this.MySpecialThingHappened();

--

Where the event should default to System.Action and the compiler could emit the bytecode to make sure a nullpointer call would be skipped.

But why would you call a method (although empty) when you don't have too? it works but it's dirty. The way i do it is by having an OnUpdated method that checks the null condition and call the handler.

@DaRage: it's all about readability and usability.  It's less code to write, easier to read, and the perf hit of calling an empty method is vanishingly small anyway.  Having to check the delegate for null has always irked me. IMO the empty delegate assignment Rob describes should happen automagically and invisibly when an event is declared.

I'm curious what is faster: always checking for null eventhandler, or calling empty function? Did you check this?

The disadvantage here is that you are allocating an extra object (the anonymous delegate) for each event on every instance of your object, which may seem trivial but it adds up when you have hundreds or thousands of objects.

The original design seems to be for performance reasons - events that no one signs up for don't incur any overhead, until you do sign up for an event and it becomes a MulticastDelegate or whatever.

The null check is annoying and I'm sure the language designers agree, but I view it as a necessary evil.

Interesting. I've checked pls's suggestion for an average of ten iterations of 10,000,000 calls to either one of the possible event calling techniques:

1. A "regular" event with no registered delegates and a null check before calling it.

2. A "ghost" event with no OTHER registered delegates and no null check before calling it.

And the results are (in average): Technique number 2 is approximately 5 times slower than the null check. (456ms vs. 88ms)

Still, I think it's worth it, unless the event is raised VERY frequently.

Thanks for the post!

@JohnB - This is not required in VB because the compiler is smart enough to add this check for you.

I did a small time test comparing checking for null and using the empty function. First I did it without subscribing and then with subscribing. For me the checking for null was ~2.5 times faster but I had to do a lot of iterations (100000) to get any of them to register on the millisecond scale.  I will be using the empty function approach since the checking for null thing has bothered me for quite some time.

Pingback from  Dew Drop - March 21, 2008 | Alvin Ashcraft's Morning Dew

This code is not thread-safe:

# if(Updated != null)  

#         Updated(this, new MarketFeedEventArgs(tickerSymbol, newPrice, newVolume));

There is a race condition between the check and the invoke where the handler might be removed in another thread.

You should invoke a local copy of the event:

# var local = Updated;

#

# if(local != null)  

#         local(this, new MarketFeedEventArgs(tickerSymbol, newPrice, newVolume));

which is even worse as boilerplate code.

pls: In my timings I saw no difference.

>> I'm curious what is faster: always checking for null eventhandler, or calling empty function?

I haven't actually checked it, but I cannot imagine a null reference check (which is essentially 2 MSIL instructions) taking longer that calling a function through a multicast delegate -- particularly since before it does call it, the delegate will do it's own null reference check (so it can throw the exception).  

And remember, it's always doing that extra call, whether there is another event attached or not.  (However, the more events attached, the smaller the proportion the time spend on this one is compared to the rest of the method)

To put this into prospective, let's pull numbers completely out of the air, and look at the example at the top of this article.

Assuming no other events attached:

The two assignment will take maybe one tick each.

The null check will take maybe two ticks, for a total of FOUR for the standard method.

on the other hand, the empty function may take one tick for the call & return, but the multicast dispatcher could easily take  35 to 75 ticks (look at it in Reflector). So were up to FORTY to eighty ticks --- 10X to 20X the standard.

Now with one real event handler attached, the numbers change a bit.

For the standard method, we have the 4 ticks we had for the empty delegate above, plus the multicast overhead, so were still in the range of 40-80 but now plus X ticks -- the time it takes that event handle to run, which is a complete wildcard.

Finally, we have the new method, with an event handler attached.  Here, we save a bit on the null comparison, but lose a slight bit more having the dispatcher loop twice instead of once.

So, the number are 4 vs ~40 and ~42+X vs ~45+X  

(keeping in mind this are totally bogus numbers, based on an educated guess)

which means if you can expect that the event will generally have a handler attached, this method will add a small delay, but it will probably get lost in the mix -- particular if the event is in response to a UI action, which will be the real time limiting factor.

On the other hand, if having an handler attached is a rare occurrence, particularly  if the event is fired a lot, (e.g. a "ItemAdded" event during the initial filling of a list), then you could be adding significant overhead.

I would say that this pattern is less efficient than checking for null since the event arguments class has to be instanciated even if it's not going to be used.

I think Yuval Löwy of IDesign should be credited for this "tricks". He discuss thread-safe event handling in his Programming .NET Componet (2. ed) (O'Reilly) where he introduces the anonymous delegate instance. Check out his excellent book - if I remember correctly, you will have to add some extra sugar really be sure the event handling is thread-safe.

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #58

So, what's the conclusion?

Check out this blog posting.  This guy may have ripped you off!

www.dev102.com/.../a-new-pattern-for-event-declaration

I think this guy jacked your post!

www.dev102.com/.../a-new-pattern-for-event-declaration

Events, Generics and Extension Methods

Events, Generics and Extension Methods

Pingback from  .net Pattern fuer Event Implementierung | LieberLieber Software TeamBlog