When in doubt, Maybe can help you

I am slowly but firmly falling in love with the functional approach to programming.

I know, it is not a silver bullet and it cant solve all of your problems, but there are aspects of functional style programming that I am beginning to appreciate more and more.

Take for example Monads. There is a whole lot of talk about monads, monoids and whatnot floating around the intertubes, and through all that almost hard core mathematical chatter that is sometimes quite hard to see what one can benefit from using such a convoluted concept.

Specially you get this question a lot when talking to Java programmers. Functional style programming can feel quite awkward in Java, with all the character noise inner classes bring with them, but sometimes it is not all that bad.

Some of the functional style concept I've been exploring lately is what Haskell calls the Maybe monad. (Scala has it in it's Option class)

Essentially, the Maybe class is all about entirely elliminating null references out of existence and handling the optionality of values in an arguably much nicer way, making things that may or may not have a value much more explicit in code by explicitly stating this using a type system.

When in Java you have an object type (which is nearly everything floating around in an average program these days), anything that gets passed to you from an "untrusted source" may or may not reference an actual object.

The trouble is that the amount of "untrusted sources" is sometimes quite difficult to track. Apart from the explicit user input that you should almost never trust with your life to be of any useful format, there are much more subtle sources that mostly do what you expect but every now and then throw you a curveball, by throwing an occasional null where you the least expect it from.

So basically, when programming in Java you are constantly walking a minefield of possible null references. If you know what NPE stands for, you probably know what am I talking about.

One way to counter it, would be to use a Maybe monad. I know there are several variations of Maybe/Option implementations floating around, but I will silently ignore all of them and go with my own concoction.

First a little appetizer, that would hopefully also serve to explain some of the reasons I find functional style programming so nice:


An awful lot of code? Lets just strip away all the inner class creation boilerplate and see how would it look like if java had closures (as it probably will in version 8):


The boilerplate of inner class creation apart, the code is actually quite clean and easy to reason about. At least for me. Lets see what is going on here:

First I get an instance of a resource from some cache. Since I don't really know if the resource is in the cache, I wrap it in a Maybe instance.

Then I check for some conditions on a returned resource. See how I do not have to check if the resource is null? This is because the predicate function (I am using Google Guava api here) is only called if the resource instance was returned from cache, so by the contract, the resource passed to the when method can never be null.

The or method will return the value contained in the Maybe instance or evaluate the provided function in case the value is missing either by virtue of not being present in the presumed cache or not passing the predicate above.

As a last step, I use a transformation function that uses the Resource and turns it into an Entity, returning an instance of Maybe<Entity> to the caller.

What this all boils down to is a set of clearly defined instructions to retrieve a value from an untrusted source (or sources). If any of the steps fails, the following steps that need an input value will be gracefully skipped, or alternative methods of arriving at the result will be consulted.

Clean, easy to follow and null-safe.