Question

This seems odd to me — VB.NET handles the null check implicitly via its RaiseEvent keyword. It seems to raise the amount of boilerplate around events considerably and I don’t see what benefit it provides.

I’m sure the language designers had a good reason to do this.. but I’m curious if anyone knows why.

Answer 1

It’s certainly a point of annoyance.

When you write code which accesses a field-like event within a class, you’re actually accessing the field itself (modulo a few changes in C# 4; let’s not go there for the moment).

So, options would be:

• Special-case field-like event invocations so that they didn’t actually refer to the field directly, but instead added a wrapper

• Handle all delegate invocations differently, such that:

  Action<string> x = null;
  x();
  

  wouldn’t throw an exception.

Of course, for non-void delegates (and events) both options raise a problem:

Func<int> x = null;
int y = x();

Should that silently return 0? (The default value of an int.) Or is it actually masking a bug (more likely). It would be somewhat inconsistent to make it silently ignore the fact that you’re trying to invoke a null delegate. It would be even odder in this case, which doesn’t use C#’s syntactic sugar:

Func<int> x = null;
int y = x.Invoke();

Basically things become tricky and inconsistent with the rest of the language almost whatever you do. I don’t like it either, but I’m not sure what a practical but consistent solution might be…