As the most common exceptions in my project are NullReferenceExceptions I'm trying to find a way to limit the occurrence of problems with unexpected or unhandled nulls to the minimum.

One of the possible solutions is to user Option monad or Result. As I understand, those guarantee two things:

  1. There will always be an instance of object to work with (because null now becomes an object)
  2. Programmer will be required to consider fail scenarios, because he can’t get to the underlying value without acknowledging the possibility of the two states that the value could be in.

Now, assuming I've added:


parameters to C# 8's csproj file in my project, is there any reason I would still use Result monad?

  1. You can't assign null to non-nullable variable now.
  2. As you get Nullable object now, it means that you need to check if it .HasValue first
  • im tempted to write an answer, but it would be very short : "No because those are for functional programming, not preventing nulls." Really need some more background as to why the pre <nullable> c# green underlines and other warnings were not effective to such an extent that you went semi functional?
    – Ewan
    Commented Apr 7 at 12:15
  • 4
    Typical Option implementation support nesting, e.g. Option<Option<Foo>>. Nullable types cannot distinguish Null from Some(Null). They also cannot carry an error message on the Null case, whereas a Result can.
    – amon
    Commented Apr 7 at 12:26
  • 3
    Just to counter point 1, meet my friend null!, who you can still assign. And that's not even pointing out that you cannot guarantee that external libraries correctly used nullable types and never pass a null to a non-nullable type. The nullability feature is a good addition and I like it a lot, but it is not an ironclad defense.
    – Flater
    Commented Apr 7 at 13:11
  • 3
    100% "oh good youve turned nullable on!.... wait whats the ! operator? and why are there so many?"
    – Ewan
    Commented Apr 7 at 13:39

1 Answer 1


Option types and checked nullability largely solve the same problem, but there a few significant differences.

  • Checked nullability in C# is not is not totally safe. It is more like a lint than a true type check. Some scenarios will not be detected correctly and it is easy to circumvent the check by applying the ! operator. So a non-nullable reference might still be null due to a bug or oversight in the code.

  • Nullability does not nest. For example if looking up a key in a dictionary, option types can distinguish between the key not existing and the key existing but the value being absent. Nulls does not support a similar distinction. Perhaps an edge case, but shows that option types are more expressive.

  • With the conditional operator "?." there is a convenient build-in way to navigate a chain of nullable members and the ?? operator gives an easy fallback for null values. Option types does not have quite as convenient syntax, although switch expressions and pattern matching improves it quite a lot.

  • nulls are a special built-in value while Option-types are standard C# types. This makes Option types a lot more malleable since you can define your own variants.

I believe option types are are technically better and safer than the use of nulls. Nevertheless I prefer to use nulls to represent missing or uninitialized values since this is the standard in .net, so this is how the standard library on most third-party library will do it. Adding option types will just introduce two different ways to check for uninitialized and missing values which will introduce additional complexity, which I don't think is justified.

  • Key existing but value being absent? What would be a usage for such thing? Honestly, sounds like a broken, confusing design. Its like: yes, it is doable, but no, you shouldn't do this.
    – freakish
    Commented Apr 8 at 10:18
  • @freakish: It's just an example, the point being options can nest but nullability can't.
    – JacquesB
    Commented Apr 9 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.