Rinat Abdullin

My last Zen dev article on Maybe Monad for C# had caused quite a few arguments and comments coming from different directions.

To make the information exchange slightly more efficient, I've composed a few additions for the article:

• Questions and Answers
• Caveats

You can find this new content either below or in the original article that had been updated. All new major updates on the topic will be delivered in the same way.

Questions and Answers

Question: Why add another needless layer of complexity for such a simple task? Just learn how to use the null coalescing operator (??) and/or inline if-thens.

Console.WriteLine(number != null ? "True" : "False");
Console.WriteLine(number ?? "Null Value");

Imagine a large real-world project that spawns multiple components and tiers, while facing problems slightly more challenging, than writing output to the console. If developers know that this project uses Maybe to declare potentially empty variables, then they are completely freed from checking for nulls and even thinking about that. That's one less thing to bother, making quite a difference in complex scenarios (and human being can simultaneously bother only about 7 things max, anyway).

This actual usage of Maybe{T} might happen in just one or two methods of the project. However, when developers use them, they will know immediately (and not from the documentation) and will be forced to handle them because of the syntax.

Things like that reduce development friction and allow complex project to be delivered efficiently and with really small teams.

Question: How is this different from Nullable{T} in C#?

Only value types are supported by Nullable generic (or its shorthand syntax). So you can't use a class variable in a nullable type (which makes sense, since the reference itself can be null).

Question: Why do Lokad Shared Libraries feature null checks, although Maybe{T} is declared in the code?

Because Lokad.Shared.dll, as a really lightweight library, might be used in various projects. Some of these projects might not have "no nulls returned and expected" policy. So it is logical to protect shared methods from the nulls explicitly. in order to avoid the unpredictable behavior.

Question: How do I use Maybe{T} if method can fail because of the multiple reasons and I want to know them?

Maybe{T} on its own is not designed to handle such situations. These are the primary logically-complete solutions for this situation:

• You can return Maybe{T} while printing multiple failure details to the IScope passed as an argument. That's how Lokad Rules are working. It also works well in long-running complex (especially asynchronous) operations that require logging and detailed failure control.
• You can use Result{TValue,TError} monad returning strongly-typed error result (i.e.: enumeration value) or it's generic counterpart Result{TValue} (if the strong-typing is not possible for some reason).
• You can always use good old exceptions, if the above options do not suite you for some reason and you are OK with try-cath and breaking the functional code flow.

Caveats

This approach, as any other piece of knowledge from the xLim body of knowledge, might be controversial and not applicable for you projects, development practices and beliefs.

All that I can say - it works for me, allowing slightly more efficient delivery, evolution and maintenance of .NET development projects ranging from business analytics servers, RESTful NoSql automation engines and up to Smart Client applications with reusable MVC infrastructure shards.

This limited improvement in development efficiency sometimes requires using approaches and principles that may be somewhat incompatible with the traditional ones (MS .NET or Alt.NET), while continuously enforcing them across the codebases. But in the end, I think, it's worth it, just like Continuous Integration or Inversion of Control.

But again, that's the way of Zen - everybody has his own way to satori.

As this is an update article, all comments are disabled here. Please use original article on Maybe Monad for sharing your feedback (which is welcome and appreciated).