Programming problems can be complex; and the best way to tackle any complex problem is to break it down into smaller problems to be solved individually. We may do this for many iterations until we end up with many tiny classes or functions that can be composed to solve our initial problem. Better yet, we may compose them in a different way to solve another problem when requirements change.

I've been programming in Elixir and I love how the |> (pipe operator) lets me easily compose functions together.

|> CSV.decode(headers: true)
|> Enum.reverse
|> Enum.take(opts[:take])
|>, &1)))

It is very obviously what this snippet of code does. The pipe operator lets you write code that follows the logic in your head. It helps the readability so much. Write code this way is both fun and rewarding!

However, the pipe operator has its limit.

I've been working on a Phoenix app lately, and one of the features is to allow a customer to send feedback via SMS to a store's dashboard. Specifically, the following steps are required to be performed sequentially.

  1. assert_valid_phone_number_format(phone_number)
  2. find_or_create_customer
  3. add_customer_to_store(store)
  4. create_feedback(message)

Each of these methods may fail, so they return either {:ok, value} or {:error, reason} tuple. If any one of the steps fails, the remaining steps should not be performed and should immediately halt and return an error.

We can no longer chain them with pipe operator as the methods are not expecting the tuple we see above as its input. Of course, we can use nested case statements to make it work again, but it is not only ugly, but also cumbersome to maintain.

Another naive approach is to have each method matching the tuple as its input. For example, instead of the following method,

def find_or_create_customer(phone_number) do
  # ...

we would have:

def find_or_create_customer({:ok, phone_number}) do
  # ...

def find_or_create_customer({:error, reason}) do
  # ...

But we've just made this method not friendly reusable in other places. Ideally, I would still want to be able to call find_or_create_customer(phone_number).

Let's see what we can do.

Error monad

We can use the error monad from this library

I don't want to get into another monad blog post. There are plenty of good ones out there. You don't need to understand monads, and friends (functor, applicative functor, etc.), as well as the theory behind to get the benefits from using monad in our case (but if you want to, do some googling or grab a Haskell book and start reading :p).

To simplify it, we can think that monad is encapsulating the code that deals with {:ok, value} and {:error, reason} tuples, so that we can compose these methods to get the effect we want: execution terminates immediately when any of the steps fails and returns the error result from the last executed step.

All methods return one of the tuples that the error monad expects, so we can use the special error monad pipe operator provided by the library.

Error.p do
  |> find_or_create_customer
  |> add_customer_to_store(store)
  |> create_feedback(message)

case result do
  {:ok, value} -> # ...
  {:error, reason} -> # ...

The with keyword introduced in Elixir 1.2

Take a look at the awesome introduction of with by José Valim here:

So our new code becomes:

with {:ok, phone_number} <- assert_valid_phone_number_format(phone_number),
     {:ok, customer} <- find_or_create_customer(phone_number),
     {:ok, customer} <- add_customer_to_store(store, customer),
     {:ok, feedback} <- create_feedback(message)
     do: {:ok, feedback}

This solution is a bit more verbose and we are not using the pipe operator anymore (if you prefer it like I do), but the upside is that we don't need a third-party library to achieve compose these functions anymore.