For example, in the type system we do not have separation between value and reference types and nullability of types. This may sound a little wonky or a little technical, but in C# reference types can be null, such as strings, but value types cannot be null. It sure would be nice to have had non-nullable reference types, so you could declare that ‘this string can never be null, and I want you compiler to check that I can never hit a null pointer here’.
50% of the bugs that people run into today, coding with C# in our platform, and the same is true of Java for that matter, are probably null reference exceptions. If we had had a stronger type system that would allow you to say that ‘this parameter may never be null, and you compiler please check that at every call, by doing static analysis of the code’. Then we could have stamped out classes of bugs.
Instead of being able to send null DateTime, the WS dictates that the client must send something. Therefore, the client sends Epoch date thus the code must handle this properly.
What about dealing with Database when NULL actually means something (in certain situation, we do want to put NULL instead of some random value/junk).
IIUI Anders isn't suggesting that null isn't necessary, but that you should be able to say in code: this type does not allow nulls (or this type does allow nulls). We have this with value types, int or int?, but not with reference types. Adding this in at the start would have removed many chances for bugs.
E.g. I frequently need to check if params are null and then throw an exception at run time. If I could declare a param as requiring a value then the error could usually be caught at compile time.
> At the end of the day, it all depends on your developers.
Sort of. In your WS example, if you had better developers then they could have defined the interface to accept Nullable<DateTime> instead of DateTime. So the language does let you express that null is an allowed value.
The feature request for the language is to make it possible to express Nonnullable<MyClass>. Regardless of your developers, the best that they would be able to do is throw an ArgumentNullException (which I see thrown for all over the place) without that support.
I'll accept that there may be a situation where a client sends junk to a service, and the service treats the junk as null, but that requires both sides to be in on it - in which case, they would be able to agree to a signature change instead. But they can only agree to the signature change if the language supports it.
