Raising events

[CuriousGeorge]

Can someone explain why this code DOES NOT raise a null reference exception?
//////////////////////////// Program.cs
/////////////////////////////////////////////
using System;
using System.Collecti ons.Generic;
using System.Text;
using CSharpLib;

namespace CSharpConsole
{
class Program
{
private EventHandler handler;
private Class1 obj;

static void Main(string[] args)
{
(new Program()).RunT est();
Console.ReadKey (true);
}

private Program()
{
obj = new Class1();
handler = new EventHandler(Do Something);
}

private void RunTest()
{
obj.SomeEvent += handler;

obj.RaiseEvent( delegate { obj.SomeEvent -= handler; });
}

private void DoSomething(obj ect sender, EventArgs e)
{
Console.WriteLi ne("foo");
}
}
}
//////////////////////////// Class1.cs
/////////////////////////////////////////////
using System;
using System.Collecti ons.Generic;
using System.Text;

namespace CSharpLib
{
public class Class1
{
public event EventHandler SomeEvent;

public delegate void Callback();

public Class1()
{
}

public void RaiseEvent(Call back callback)
{
EventHandler temp = SomeEvent;

callback();

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

[Peter Duniho]

"CuriousGeo rge" <***@***.comwro te in message
news:Ot******** ********@TK2MSF TNGP03.phx.gbl. ..

Can someone explain why this code DOES NOT raise a null reference
exception?

Because no nulls are referenced?

If you have reason to believe that a null reference exception should occur,
then the least you could do is explain in your post:
a) why it is you want to execute code like this, and
b) why and where it is that you think a null reference exception would
occur

Pete

[Dave Sexton]

Hi,

Where do you expect a null reference exception to be raised?

This line is checking to make sure temp is not null before it's used in
Class1:

if (temp != null)

--
Dave Sexton

"CuriousGeo rge" <***@***.comwro te in message
news:Ot******** ********@TK2MSF TNGP03.phx.gbl. ..

Can someone explain why this code DOES NOT raise a null reference exception?
//////////////////////////// Program.cs
/////////////////////////////////////////////
using System;
using System.Collecti ons.Generic;
using System.Text;
using CSharpLib;

namespace CSharpConsole
{
class Program
{
private EventHandler handler;
private Class1 obj;

static void Main(string[] args)
{
(new Program()).RunT est();
Console.ReadKey (true);
}

private Program()
{
obj = new Class1();
handler = new EventHandler(Do Something);
}

private void RunTest()
{
obj.SomeEvent += handler;

obj.RaiseEvent( delegate { obj.SomeEvent -= handler; });
}

private void DoSomething(obj ect sender, EventArgs e)
{
Console.WriteLi ne("foo");
}
}
}
//////////////////////////// Class1.cs
/////////////////////////////////////////////
using System;
using System.Collecti ons.Generic;
using System.Text;

namespace CSharpLib
{
public class Class1
{
public event EventHandler SomeEvent;

public delegate void Callback();

public Class1()
{
}

public void RaiseEvent(Call back callback)
{
EventHandler temp = SomeEvent;

callback();

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

[CuriousGeorge]

Because no nulls are referenced?
Hmmm. OK.

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

b) Events are basically delegates, System.Delegate is a reference type,
there's nothing special about it, it overloads += and -= but other than that
its a pretty vanilla type.

As we know and event with no subscribers is actually a null-reference hence
the check for nullility before invoking the subscribed handlers.

If you in-line the delegate call in my original post you get something like
the following (compiled in Outlook Express)

public void RaiseEvent(Call back callback)
{
EventHandler temp = SomeEvent;

SomeEvent -= theOnlyRegister edEventHandler
//SomeEvent is now null

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

The code in my original post draws the understanding reader to the
conclusion that this particular reference type is not obeying standard
reference type semantics. I thought it was pretty self-explanatory.
"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** *****@corp.supe rnews.com...

"CuriousGeo rge" <***@***.comwro te in message
news:Ot******** ********@TK2MSF TNGP03.phx.gbl. ..

>Can someone explain why this code DOES NOT raise a null reference
exception?

Because no nulls are referenced?

If you have reason to believe that a null reference exception should
occur, then the least you could do is explain in your post:
a) why it is you want to execute code like this, and
b) why and where it is that you think a null reference exception would
occur

Pete

[Mark R. Dawson]

Hi,

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

I don't see anything particularly thread safe about your code, are you
talking about checking for null that makes this thread safe? It is safe for
a single thread but once you have multiple threads the really only safe way
is to make sure you have locks in place around adding/removing delegates to
your event and the invocation of that event i.e. the following is an example
of how two threads accessing the same event can cause a null reference
exception:

using System.Threadin g;

namespace CSharpConsole
{
class Program
{
static void Main(string[] args)
{
TestClass t = new TestClass();
t.Run();
}
}

class TestClass
{
private delegate void MyEventHandler( );
private event MyEventHandler MyEvent;

public TestClass()
{
}

public void Run()
{
Thread threadA = new Thread(new ThreadStart(Thr eadADoSomething ));

//Add listener to the event
MyEvent += new MyEventHandler( DoSomething);

if (MyEvent != null)
{
//got in here, let the other thread run and wait until it
//completes
threadA.Start() ;
threadA.Join();

//whoops now this is null
MyEvent();
}
}

void ThreadADoSometh ing()
{
//removes the only listener
MyEvent -= new MyEventHandler( DoSomething);
}

void DoSomething()
{
}
}
}

b) Events are basically delegates, System.Delegate is a reference type,
there's nothing special about it, it overloads += and -= but other than that
its a pretty vanilla type.

There is a little bit more to this type, hence your posting :-) If you look
at the documentation for the delegate type you will see: "Delegates are
immutable; once created, the invocation list of a delegate does not change."
Hence the reason why when you assign you event (which is really just
syntactic sugar around delgates) to your other delegate type really you have
just made a new copy of that delegate. The contents of the
multicastdelega tes invocation list inside the temp variable will therefore
not change when you update the other multicastdelega te through the SomeEvent
enty point.

The code in my original post draws the understanding reader to the
conclusion that this particular reference type is not obeying standard
reference type semantics. I thought it was pretty self-explanatory.

Why not just ask the question you want to ask :-)
--
http://www.markdawson.org
Posted from Windows Vista RC1

"CuriousGeo rge" wrote:

Because no nulls are referenced?

Hmmm. OK.

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

b) Events are basically delegates, System.Delegate is a reference type,
there's nothing special about it, it overloads += and -= but other than that
its a pretty vanilla type.

As we know and event with no subscribers is actually a null-reference hence
the check for nullility before invoking the subscribed handlers.

If you in-line the delegate call in my original post you get something like
the following (compiled in Outlook Express)

public void RaiseEvent(Call back callback)
{
EventHandler temp = SomeEvent;

SomeEvent -= theOnlyRegister edEventHandler
//SomeEvent is now null

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

The code in my original post draws the understanding reader to the
conclusion that this particular reference type is not obeying standard
reference type semantics. I thought it was pretty self-explanatory.
"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** *****@corp.supe rnews.com...

"CuriousGeo rge" <***@***.comwro te in message
news:Ot******** ********@TK2MSF TNGP03.phx.gbl. ..

Can someone explain why this code DOES NOT raise a null reference
exception?

Because no nulls are referenced?

If you have reason to believe that a null reference exception should
occur, then the least you could do is explain in your post:
a) why it is you want to execute code like this, and
b) why and where it is that you think a null reference exception would
occur

Pete

[CuriousGeorge]

"Delegates are immutable; once created, the invocation list of a delegate
does not change."

Word. Thanks Mark, I hadn't seen that bit of doco. The thing is, I did skim
the (managed) rotor source for delegates and saw nothing that suggested
immutability in the implementation. Forgive my ignorance but where in the IL
can I see this? (is it a type decorator)

"Why not just ask the question you want to ask :-)"

Quite simply, I don't have the expertise to express myself very well.

Case in point, immutability, I see it, I hear it, it is said by the oracle,
MSDN, however, the upshot is (to all intents and purposes) that the
assignment operator behaves like it is overloaded such that it works like a
value type. I have taken this as gospel for years with the System.String
class but now I see it here and it is making my head spin!!

Words fail me.

Please help :)
"Mark R. Dawson" <Ma*********@di scussions.micro soft.comwrote in message
news:A1******** *************** ***********@mic rosoft.com...

Hi,

>a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

I don't see anything particularly thread safe about your code, are you
talking about checking for null that makes this thread safe? It is safe
for
a single thread but once you have multiple threads the really only safe
way
is to make sure you have locks in place around adding/removing delegates
to
your event and the invocation of that event i.e. the following is an
example
of how two threads accessing the same event can cause a null reference
exception:

using System.Threadin g;

namespace CSharpConsole
{
class Program
{
static void Main(string[] args)
{
TestClass t = new TestClass();
t.Run();
}
}

class TestClass
{
private delegate void MyEventHandler( );
private event MyEventHandler MyEvent;

public TestClass()
{
}

public void Run()
{
Thread threadA = new Thread(new
ThreadStart(Thr eadADoSomething ));

//Add listener to the event
MyEvent += new MyEventHandler( DoSomething);

if (MyEvent != null)
{
//got in here, let the other thread run and wait until it
//completes
threadA.Start() ;
threadA.Join();

//whoops now this is null
MyEvent();
}
}

void ThreadADoSometh ing()
{
//removes the only listener
MyEvent -= new MyEventHandler( DoSomething);
}

void DoSomething()
{
}
}
}

>b) Events are basically delegates, System.Delegate is a reference type,
there's nothing special about it, it overloads += and -= but other than
that
its a pretty vanilla type.

There is a little bit more to this type, hence your posting :-) If you
look
at the documentation for the delegate type you will see: "Delegates are
immutable; once created, the invocation list of a delegate does not
change."
Hence the reason why when you assign you event (which is really just
syntactic sugar around delgates) to your other delegate type really you
have
just made a new copy of that delegate. The contents of the
multicastdelega tes invocation list inside the temp variable will therefore
not change when you update the other multicastdelega te through the
SomeEvent
enty point.

>The code in my original post draws the understanding reader to the
conclusion that this particular reference type is not obeying standard
reference type semantics. I thought it was pretty self-explanatory.

Why not just ask the question you want to ask :-)
--
http://www.markdawson.org
Posted from Windows Vista RC1

"CuriousGeo rge" wrote:

Because no nulls are referenced?

Hmmm. OK.

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

b) Events are basically delegates, System.Delegate is a reference type,
there's nothing special about it, it overloads += and -= but other than
that
its a pretty vanilla type.

As we know and event with no subscribers is actually a null-reference
hence
the check for nullility before invoking the subscribed handlers.

If you in-line the delegate call in my original post you get something
like
the following (compiled in Outlook Express)

public void RaiseEvent(Call back callback)
{
EventHandler temp = SomeEvent;

SomeEvent -= theOnlyRegister edEventHandler
//SomeEvent is now null

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

The code in my original post draws the understanding reader to the
conclusion that this particular reference type is not obeying standard
reference type semantics. I thought it was pretty self-explanatory.
"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******* ******@corp.sup ernews.com...

"CuriousGeo rge" <***@***.comwro te in message
news:Ot******** ********@TK2MSF TNGP03.phx.gbl. ..
Can someone explain why this code DOES NOT raise a null reference
exception?

Because no nulls are referenced?

If you have reason to believe that a null reference exception should
occur, then the least you could do is explain in your post:
a) why it is you want to execute code like this, and
b) why and where it is that you think a null reference exception
would
occur

Pete

[Peter Duniho]

"CuriousGeo rge" <***@***.comwro te in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

I disagree. As Mark points out, there's nothing thread-safe about the code
that you posted.

[...]
The code in my original post draws the understanding reader to the
conclusion that this particular reference type is not obeying standard
reference type semantics. I thought it was pretty self-explanatory.

Well, hopefully at this point, given the responses you've seen, it should be
clear to you that it was NOT "pretty self-explanatory".

On the bright side, it looks like you did finally get the answer to your
question. :)

Pete

[Jon Skeet [C# MVP]]

CuriousGeorge <***@***.comwro te:

Because no nulls are referenced?

Hmmm. OK.

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

It's not, actually. Your code isn't genuinely thread-safe. See
http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml for a
genuinely thread-safe pattern.

b) Events are basically delegates

No they're not. Events are pairs of methods. Field-like events declare
both an event and a delegate.

System.Delegate is a reference type,
there's nothing special about it, it overloads += and -= but other than that
its a pretty vanilla type.

Actually, it *doesn't* overload += and -=. Instead, the C# compiler
calls Delegate.Combin e or Delegate.Remove , both of which are static
methods which can take null arguments.

See http://www.pobox.com/~skeet/csharp/events.html for more
information.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@Nn OwSlPiAnMk.comw rote:

"CuriousGeo rge" <***@***.comwro te in message
news:%2******** **********@TK2M SFTNGP02.phx.gb l...

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

I disagree. As Mark points out, there's nothing thread-safe about the code
that you posted.

In fairness to the OP, I wouldn't go that far. It's not *quite* thread-
safe, but it's safer than the normal pattern of:

if (EventName != null)
{
EventName (...);
}

where "EventName" is a field-like event.

The problem with the above is that another thread could change the
value of myEventName to null between the check and the call. The OP's
code tries to avoid that by using a local variable. Now, there's some
debate as to the exact guarantees of behaviour of local variables in
the memory model, but it's at least a reasonable start. However, the
lack of locking and volatility means that if one thread adds a load of
event handlers, they may never be noticed by the thread raising the
event, which isn't generally what's wanted.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[CuriousGeorge]

Jon, your arachsys stuff is, quite simply, GOLD

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

CuriousGeorge <***@***.comwro te:

Because no nulls are referenced?

Hmmm. OK.

a) "Code like this" is the preferred way to raise events in a thread safe
manor - you should be doing it yourself.

It's not, actually. Your code isn't genuinely thread-safe. See
http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml for a
genuinely thread-safe pattern.

>b) Events are basically delegates

No they're not. Events are pairs of methods. Field-like events declare
both an event and a delegate.

>System.Delegat e is a reference type,
there's nothing special about it, it overloads += and -= but other than
that
its a pretty vanilla type.

Actually, it *doesn't* overload += and -=. Instead, the C# compiler
calls Delegate.Combin e or Delegate.Remove , both of which are static
methods which can take null arguments.

See http://www.pobox.com/~skeet/csharp/events.html for more
information.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too