On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen
wrote:
Out of curiosity: Why? How often does your code actually
accept null as
a valid state of a class reference?
I have no idea. I know that it's a non-negligible amount of the
time, though
it's certainly true that they normally have values. But null is
how you
indicate that a reference has no value. The same goes for
arrays and pointers.
Sometimes it's useful to have null and sometimes it's useful to
know that a
value can't be null. I confess though that I find it very
surprising how much
some people push for non-nullable references, since I've never
really found
null to be a problem. Sure, once in a while, you get a null
pointer/reference
and something blows up, but that's very rare in my experience,
so I can't help
but think that people who hit issues with null pointers on a
regular basis are
doing something wrong.
- Jonathan M Davis
In my experience this sort of attutide is not workable in
projects with more than one developer.
It all works OK if everyone knows the 'rules' about when to check
for null and when not to.
Telling team members that find bugs caused by your null
references that they are doing it wrong and next time should
check for null is a poor substitute for having the language
define the rules.
A defensive attitude of checking for null everywhere like I have
seen in many C++ projects makes the code ugly.
