Question

When calling a delegate you always have to check if it is not null. This is an often cause for errors.
Since delegates are more or less just a list of functions, I would assume, that this could have been easily checked by the delegate itself.

Does anybody know, why it has been implemented as it is?

Answer 1

I’d guess the reasons are history and consistency.

It is consistent with the way other types are handled; e.g. there’s no language or platform assistence in dealing with nulls – it’s the programmers responsibility to ensure the null placeholder is never actually used – there’s no means of only optionally calling a method if the object reference you wish to call it on is non-null either, after all.

It’s history, since null references happen to be included by default in most types, even though this isn’t necessary. That is, rather than treating reference types like value types and require an additional “nullability” annotation to permit nullability, reference types are always nullable. I’m sure there were reasons for this back in the day when Java and .NET were designed, but it introduces many unnecessary bugs and complexities which are easy to avoid in a strongly typed language (e.g., .NET value types). But given the historical inclusion of null as a type-system wide “invalid” value, so to speak, it’s only natural to do so for delegates as well.