It would be a great world if everything ran without errors. Validating inputs from users and handling various other kinds of error ranging from databases access, file access, network issues or any other is a reality of the software. We all have written programs where the cases of handling erros are so much that it increases the codebase by manifold. This make the life of the maintainer a hell, yet this is something that has to be done. Even the most simplest program when changed to handle various kinds of error just makes the code inelegant. I started learning functional programming and it was a breeze to write software without introducing common bugs but error handling is still a reality. Wondering how error handling can be done in an elegant way I stumbled upon a talk by Scott Wlaschin where he describe Railway Oriented Programming (ROP). This is a great design pattern to follow which allows you to create functional programs which handle errors and yet are very readable.
# Code before error handling
request
|> validate_request
|> get_user
|> update_db_from_request
|> send_email
|> return_http_message
# Code after error handling
request
>>> validate_request
>>> (map get_user)
>>> (tee update_db_from_request)
>>> (try_catch send_email)
>>> return_http_message
How to handle errors
A typical application contains some data and some set of operations performed on it. Usually errors in an imperative language are handled by try catch or checking that the each operation(function) returned as expected and if not then return error. This causes a lot of defensive coding by adding a lot of if into the code hence making it difficult to reason about.
Now lets take how we can handle errors in a functional paradigm in a better way. Lets say that each function returns either {:ok, "data"} in case of success or returns {:error, "Failure reason"} in case of failure. We can call such function two-track functions. Now if we chain such functions then in case of error we dont want to execute rest of the functions but instead bypass them
So a railway metaphor works really well here. You have a railway track which you take in case of success and switch the track in case of failure
Elixir is awesome but it does not have a good support for currying function like Haskell or F#, but it has macros. Lets see how we can create an operator which allows us to switch tracks and chain two-track functions
defmacro left >>> right do
quote do
(fn ->
case unquote(left) do
{:ok, x} -> x |> unquote(right)
{:error, _} = expr -> expr
end
end).()
end
end
In the >>> operator macro, which we will call the bind operator, we create an anonymous function which checks that if the data is {:ok, _} then call the next function otherwise bypass calling the function and go to the next step. In this way if there is an error in any place in the track then it will bypass all other functions and at the end we will get {:error, _} which we can handle.
In this way we can chain multiple such functions and handle the error at the end by logging it or returning the same error.
Other helper macros
Creating two-track functions
Lets face it, not all functions are bad. There are some functions which we can always trust to return a valid thing or do a valid thing and they will never throw errors. We can create another macro which always changes the output from such functions to a success two-track function output.
defmacro map(args, func) do
quote do
(fn ->
result = unquote(args) |> unquote(func)
{:ok, result}
end).()
end
end
Here we call the function and then change the output to {:ok, result} format so it can be chained with other functions by the >>> bind operator.
request
>>> name_not_blank
>>> (map name_trim)
In the example name_trim is a function that calls the String.rstrip on the name in the request and returns the updated request. We know this will always result in a success hence we create a single-track function to two-track-function by using the map macro.
Dead-end functions
There are some function which will do something meaningful but wont return anything meaningful that we want to chain with other functions.
request
>>> validate
>>> update_db
>>> send_email
In the example the update_db function just updates the DB and returns something which we dont want to pass to send_email function. So what should we do here? We will create a tee macro which will call the dead-end function and then return the input back as output.
defmacro tee(args, func) do
quote do
(fn ->
unquote(args) |> unquote(func)
{:ok, unquote(args)}
end).()
end
end
In the tee macro we call the function and return the input back again.
So chaining would be as follows
request
>>> validate
>>> (tee update_db)
>>> send_email
Functions that throw exceptions
Then there are functions that still throw error and dont return the two-track output i.e. {:ok, _} or {:error, _}. We will create another helper macro which will change a function which can throw exceptions to a two-track output. Uncreatively I will name it try_catch.
defmacro try_catch(args, func) do
quote do
(fn ->
try do
{:ok, unquote(args) |> unquote(func)}
rescue
e -> {:error, e}
end
end).()
end
end
In this macro we have a try..rescue which in case of exception will convert the exception into the {:error, _} pattern and in case of success will convert the ouput to {:ok, _} pattern.
Putting it together
Now we have all these macros, lets see how we can chain multiple functions which have different behaviour using the bind operator
We have the following functions to perform on a request from user
- Validate Request (two-track): Function that validates the request values.
- Get User (one-track): Gets the user.
- Update DB (dead-end): Updates the DB and does not return anything that can be chained with other functions hence its a dead-end function whose output we dont care about.
- Send Email (can throw exception): Send email is a standard function that can throw exception.
- Return Http Message (two-track): It converts the function into an appropriate HTTP message.
request
>>> validate_request
>>> (map get_user)
>>> (tee update_db)
>>> (try_catch send_email)
>>> return_http_message
Other helpers
There can be other kind of helper macros/function as well such as a supervisor macro/function which allows you to handle both success and error inputs instead of bypassing error. Think in terms of such helpers and you would be able to make your code more easy to understand and much more maintainable.
What could be next
I think it would be great to have a Hex package that provides all such kind of helper macros & functions to make ROP much easier in Elixir which anyone can leverage in there projects.
Currently I have created a Gist which contains these macros.
Disclaimir: I have started learning metaprogramming in Elixir so there might be better ways of implementing the macros that do the same thing. Let me know what you think about it, will love to hear about it.
References
Railway Oriented Programming - F# for fun and profit
I would recommend to go through the talk if you are interested in ROP. I haven't convered all the things.
