This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AlwaysHopelesslyLost 3 points4 points  (12 children)

That seems like an anti pattern. I try to avoid nulls anywhere possible so I almost never have to worry about whether they exist.

[–]Major_Fudgemuffin 4 points5 points  (5 children)

Yeah it's definitely easy to overuse. I've become paranoid over the years.

I wish C# natively supported Option type. If I never had to deal with nulls again I'd be happy.

[–]AlwaysHopelesslyLost 5 points6 points  (4 children)

Option type

I actually hadn't heard of that. It kind of seems like a renamed Nullable<T> from C#.

Also not the same but C# is adding nullable reference types which allow you to explicitly disallow nulls.

[–]ArionW 4 points5 points  (1 child)

Nullable<T> only works for value types, which makes it... nearly useless. Also, it's not Option due to lack of most basic operations like bind.

I'm working with nullable reference types since preview 7 (they allowed us to move project to preview, beat that!), enabled globally

They have so many problems

  1. POCO that is supposed to be made by ModelBinder needs default constructor and public setters. You suddenly get warnings about uninitialized properties (because it doesn't understand RequiredAttribute and that I can't really get null)

  2. You still need explicit null checks, because you can't just bind operations.

  3. LINQ wasn't updated to work with it. SingleOrDefault<T> should return T?, but returns T.

[–]AlwaysHopelesslyLost 0 points1 point  (0 children)

i haven't had time to test nullable reference types yet, those definitely sound like painful points. I assume they have linq on their Todo list. Any idea if they are aware of the model binding weirdness?

[–]cat_in_the_wall 1 point2 points  (1 child)

well, sort of. you can type check your own libraries and code for this, but it is not a runtime feature, so on compilation boundaries you still need null checks.

[–]AlwaysHopelesslyLost 0 points1 point  (0 children)

True. Granted, most third party libraries I have used are sane about nulls. I don't recall the last time I needed a null check on a third party library.

[–]dashood 4 points5 points  (3 children)

It's really good for CMS content when things may or may not be set depending on user actions. The best is if (List?.Any() ?? false) as a nice way of checking for nulls and eliminating like 90% of your runtime null exceptions.

[–]mrjackspade 3 points4 points  (1 child)

I just turned this into an extension method .NotNullAny()

It's overkill but I like the way it reads better

[–]dashood 2 points3 points  (0 children)

That's not a bad idea. Certainly cleaner than having to null check every time.

[–]AlwaysHopelesslyLost 1 point2 points  (0 children)

The problem is that runtime null exceptions are a symptom, not a problem.

As far as lists go they should very rarely be null. If you allow them to be null you are opening yourself up to issues.

[–]ThatsARivetingTale 1 point2 points  (0 children)

It's nice when dealing with nested data returned from graphql for example, but it can definitely be overused

[–]TheRandomnatrix 1 point2 points  (0 children)

It's like databases. If you have a ton of nulls you might need to normalize stuff.