Null event stupidity?

[Kevin Cline]

Why, oh why is it necessary to test an event for null before raising
it?

Why isn't that case handled automatically, instead of forcing
developers to write three lines of wasted boilerplate code every time
an event is raised:

if (SomethingChanged != null) // wasted code
{ // more waste
SomethingChanged(...)
} // more waste

instead of simply:
SomethingChanged(...)

Either the C# compiler or the CLR should handle the null case
automatically.

 

[Michael Culley]

An event is just a delegate, so what you are suggesting is that delegates should be able to be called without being instantiated and
the error ignored. In many cases you would want the error raised.

 

[Jay B. Harlow [MVP - Outlook]]

Kevin,
The VB.NET compiler does the check for you automatically, via the RaiseEvent
keyword.

Either the C# compiler or the CLR should handle the null case
automatically.

I really do not think its the CLR's place to handle the null case on a
delegate! As that would be "masking errors".

instead of simply:
SomethingChanged(...)

Remember that "SomethingChanged" is shorthand for
"SomethingChanged.Invoke()", if the CLR suddenly avoided Null Reference
Exceptions when calling a method on a Null reference, should it do it in all
cases or just in exceptional cases (no pun intended).

Hope this helps
Jay

 

[Dave Benjamin]

I really do not think its the CLR's place to handle the null case on a
delegate! As that would be "masking errors".

How do you figure? If there are no listeners, it's not an error. It's just a
message with no recipients. This model forces the programmer to say "If
anyone's listening, then say this to everyone that's listening. Otherwise,
don't say anything". How is that different from saying "Say this to anyone
that's listening"? If a tree falls in the woods....

Remember that "SomethingChanged" is shorthand for
"SomethingChanged.Invoke()", if the CLR suddenly avoided Null Reference
Exceptions when calling a method on a Null reference, should it do it in all
cases or just in exceptional cases (no pun intended).

But it's okay to use += or -= on a Null reference? You're not making any
sense here...

 

[Daniel O'Connell]

How do you figure? If there are no listeners, it's not an error. It's just a
message with no recipients. This model forces the programmer to say "If
anyone's listening, then say this to everyone that's listening. Otherwise,
don't say anything". How is that different from saying "Say this to anyone
that's listening"? If a tree falls in the woods....

An event is a field like any other when called. If its null its null, not an
event with no listeners.
While I agree that its annoying, there are other more important issues, like
thread safety.

But it's okay to use += or -= on a Null reference? You're not making any
sense here...

+= and -= eventually call Delegate.Combine() and Delegate.Remove(), which
can take null parameters. Remember, all operators are static, and a delegate
modification creates a new delegate instead of modifying the original one.

 

[Michael Culley]

How do you figure? If there are no listeners, it's not an error. It's just a
message with no recipients. This model forces the programmer to say "If
anyone's listening, then say this to everyone that's listening. Otherwise,
don't say anything". How is that different from saying "Say this to anyone
that's listening"? If a tree falls in the woods....

But that would mean creating an instance of each event delegate for each object that is created.

But it's okay to use += or -= on a Null reference? You're not making any
sense here...

Of course. += calls the static operator that takes two references as parameter and returns a reference, so is perfectly acceptable
to work on a null reference:

//not sure if this is syntatically correct but will be close
public static operator MyClass +=(MyClass Ref1, MyClass Ref2)
{
if (Ref1 == null) Ref1 = new MyClass();
.... do some sort of add here
return Ref1
}

 

[Dave Benjamin]

But that would mean creating an instance of each event delegate
for each object that is created.

Well, it's all how you look at things. I didn't understand the null behavior
very well, but I get it now (thanks to you and Daniel). But you could think
of an event as a specialized collection object that contains only delegates,
such that calling the collection as a function results in the delegates
getting called. Obviously, that's not what's really going on here, but it
would be an equally plausible solution to the multiple listener problem. In
that case, you would just add/remove delegates to these collections as
desired, and all events would be callable even if they were empty.

Anyway, thanks for the insight.

But it's okay to use += or -= on a Null reference? You're not making any
sense here...

Of course. += calls the static operator that takes two references as parameter and
returns a reference, so is perfectly acceptable to work on a null
reference... [snip]

Ahh, I hadn't realized that it worked that way. I guess that makes sense,
but it's definitely a surprise to me. For instance, the following cannot hold:

a.equals(b) <--> a == b

Because null.equals(b) would be invalid. (Not sure if that's valid
semantically in C# since I'm very new to the language).

 

[Michael Culley]

Well, it's all how you look at things. I didn't understand the null behavior
very well, but I get it now (thanks to you and Daniel). But you could think
of an event as a specialized collection object that contains only delegates,
such that calling the collection as a function results in the delegates
getting called. Obviously, that's not what's really going on here, but it
would be an equally plausible solution to the multiple listener problem. In
that case, you would just add/remove delegates to these collections as
desired, and all events would be callable even if they were empty.

That would mean that each event would need to be created when the object was created. This would make instantiating the object much
slower.

a.equals(b) <--> a == b

The == operator is defined as

public static bool operator ==(SomeObject A, SomeObject B)