0

This situation seem very interesting to me.

In C# you need to check if there is any listener to the event in a class before firing it.

Assuming event structure of C# is a non-standart(Meaning Microsoft did it) implementation of Observer observable pattern for ease of use.

Why didn't they implement this inside that structure? Is there solid reasons or documentation for this choice.

Is it a necessity do null checking, or am I wrong in my assumption for event structures needing null checks under all circumstances.

This is a more of a curiosity question looking for an answer to this implementation choice by microsoft. Which I hope will lead to further understanding of delegate and event keyword inner workings.

Ali Akdurak
  • 3,841
  • 1
  • 18
  • 16
  • Well things like user interface controls usually have lots of events but very few observers. Why do we need to give these unused events some special non-null value? – ta.speot.is Mar 13 '14 at 09:04
  • See http://stackoverflow.com/questions/170907/is-there-a-downside-to-adding-an-anonymous-empty-delegate-on-event-declaration that is also a good way to avoid checking for null. – Marek Mar 13 '14 at 09:04
  • 1
    That calling an event doesn't implicitly check for null was a dumb mistake on Microsoft's part. – CodesInChaos Mar 13 '14 at 09:06
  • Events does not need some special value. Event is a keyword which a compiler creates a list to hold delegates to call. I am wondering why didn't microsoft implemented further improvements on the concept? And asking if there is documentation or explpanation for this choice. – Ali Akdurak Mar 13 '14 at 09:09
  • No you shouldn't if you are going to see what happens when the 'null' is being called – heq Mar 13 '14 at 09:09
  • @CodesInChoas Yeah that's what I am suspecting. Also this the reason I wanted to ask this question. Because your knowledge and my knowledge maybe limited on the subject :D – Ali Akdurak Mar 13 '14 at 09:13
  • 1
    There's a reply to this question in [a blog by Eric Gunnerson](http://blogs.msdn.com/b/csharpfaq/archive/2004/03/19/why-do-i-need-a-null-test-before-i-invoke-a-delegate.aspx) Basically it seems to say that they thought about changing it, but it could break existing code. Anyway, it seems @CodesInChaos is correct. :) – Matthew Watson Mar 13 '14 at 09:14
  • @MatthewWatson Thank you. Very enlightening. Can you please make an answer with the link and some summary/explanation. I think that is the answer I am looking for. – Ali Akdurak Mar 13 '14 at 09:17
  • +1, I never actually thought about this problem. I'm adding this to my 'List of little things where VB.NET feels better than C#'. (I love C#.) You can raise whatever you want in VB.NET without a check. – GSerg Mar 13 '14 at 09:30
  • @GSerg nice I didn't know about that. So It means VB.NET's event keyword should create different IL codes than C# event keyword. I will try this. – Ali Akdurak Mar 13 '14 at 09:32

3 Answers3

3

Yes, you must do the null check.

Calling a delegate that is null results in a NullReferenceException.

You might be tempted to intialize all delegates with a non-null, empty event handler. However, that would be far worse than testing for null, in terms of CPU usage, memory usage, and lines of code.

Kris Vandermotten
  • 10,111
  • 38
  • 49
  • I definitely agree with your answer. It is basically checking a function pointer if it is pointing something to. But when we use as a event there is a list of delegates initialized behind event keyword ? What do you think about this. Would it be able to implement such list management behind the code that is created by event keyword. – Ali Akdurak Mar 13 '14 at 09:06
  • @AliAkdurak for more information, read all the answers and comments on them to this question: http://stackoverflow.com/questions/170907/is-there-a-downside-to-adding-an-anonymous-empty-delegate-on-event-declaration – Kris Vandermotten Mar 13 '14 at 09:09
  • I will check the linked question and answer. – Ali Akdurak Mar 13 '14 at 09:10
  • This link you have given provides detailed implementation benchmarks and methods for such null checking. A very good reference IMO. – Ali Akdurak Mar 13 '14 at 09:44
1

There's a reply to this question in a blog by Eric Gunnerson.

Basically it seems to say that Microsoft thought about changing it, but it would break existing code.

In other words, it was a mistake in the original design for events, but it's too late to fix it.

Matthew Watson
  • 104,400
  • 10
  • 158
  • 276
  • I think that blog post raises even more important questions about race condition from if null check as a thread can check for a delegate then enter the if block and get an interrupt. While another thread unregisters all delegates. Which makes me believe it is totaly unsafe. – Ali Akdurak Mar 13 '14 at 09:55
  • @AliAkdurak Yes, I always make a copy of the handler and check the copy for null and call the copy rather than the original, for this very reason. – Matthew Watson Mar 13 '14 at 09:57
  • Funny, the LINQ2SQL designer does not make a copy of the handler before checking: `if ((this.PropertyChanging != null)) {this.PropertyChanging(this, emptyChangingEventArgs);}` – GSerg Mar 17 '14 at 11:05
  • @GSerg If it's some user interface control then it's fine because most user interface controls are not re-entrant and can only be used on the main thread. You have no expectation of them working in a concurrent context. – ta.speot.is Mar 17 '14 at 12:13
0

You can add a default event listener, thus avoiding the null check

public Action<object, EventArgs> SomeEvent = (o, e) => { };

in that way, you can call SomeEvent without checking for null, since it contains a default (empty implementation) listener. Please note that it might hurt performance.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
user3414484
  • 1
  • You can, but IMO you should not. See [Is there a downside to adding an anonymous empty delegate on event declaration?](http://stackoverflow.com/questions/170907/is-there-a-downside-to-adding-an-anonymous-empty-delegate-on-event-declaration) for a longer discussion. – CodesInChaos Mar 13 '14 at 09:07