Crowdhailer
Add error binding to function definitions, Experimental
This example overrides Kernel.def/2, so I am aware it is only suitable as an experiment. However here are the results.
Given the functions fetch_user and fetch_cart that both return {:ok, value} or {:error, reason}.
defmodule MyApp do
use OK.Kernel
def checkout(user_id, cart_id) do
user <- fetch_user(user_id) # `<-` will bind user when fetch_user returns {:ok, user}
cart <- fetch_cart(cart_id) # `<-` will shortcut to else clause if returned {:error, reason}
order = checkout(cart, user) # Lines without `<-` behave normally
order.invoice_id
else
:user_not_found ->
IO.puts("No user for user_id: #{user_id}")
nil
:cart_not_found ->
IO.puts("User has no cart")
nil
end
end
By using OK.Kernel errors can be grouped in what I consider to be a very natural way.
I guess it’s natural because it looks like how I would arrange raise and catch in previous languages. However with the magic of Elixir macros I can do it all without using exception raising.
To try it yourself add the release candidate to your mix.exs
{:ok, "~> 1.7.0-rc.1"}
Comments welcome.
My motivation for trying this was to separate unhappy paths due to code errors ( I still raise exceptions for them) and the unhappy path due to bad input.
Most Liked
aseigo
Personally, I think this leads to hard to reason about code due to the loss of locality between the function body and the else that may or may not be triggered. It’s the same reason goto is “considered harmful” (caveats and exceptions to that aside 
)
This feels like a place where with would be a good solution. A bit of syntatic sugar around it to tease the behavior of with to automatically succeed on {:ok, anything} and fail on {:error, anything} would be nicer imho, and iirc someone recently did exactly that.
Also, I find that if I have long(er) functions where there are conditions somewhere in the middle that need to branch, such as on failure or success, that this is a signal that perhaps I should break that function there and send processing on to another function which will continue on success or return on failure.
IOW, each function goes as far as it can until need to react to a success/failure and at that point calls another function. So each function ends up being a bit-sized bit of code that does execute completely, allowing each function to be reasoned about simply and clearly.
Exceptions (or, what they really are: early returns) are a tool of “last resort” for me, used when they are really required only. Similarly for case/with/etc. If those start nesting, or a function ends up being a series of them, I take that as a code smell to start chopping that function up into more atomic sets of code to stuff into functions.
Popular in Announcing
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"