verkhovin
How to handle error handling boilerplate
Hi guys!
Want to open here another discussion about error handling concepts in Elixir because it looks like I really stuck here by myself.
My question is about errors that are related to users interactions, where you can’t just “Fail fast and forget / Let it crash” but need to respond with some appropriate error message.
Elixir community’s standard is to return tuples like {:error, reason} when something goes wrong during function execution. Overall, it looks good at the first sight.
But at some point, I noticed that to handle this approach I have to write tons of case or with really often just to check that underlying call didn’t return this {:error, reason} tuple.
Consider an example of a multilayered application (like Controller → Business Logic → database CRUDs). If there is some expected error that occurs on the layer of CRUDs, I will need to have a case to catch this error on a Business Logic layer and pass it to Controller. After that, I need to have another case on the Controller’s layer. And it becomes even worse if you have more than 3 layers there, or your business logic includes something more than just a call to CRUD layer.
Maybe I really missed something but it seems to me that this approach makes you write a lot of boilerplate.
I’m actually from Java world and it would be quite natural for me to resolve this issue by throwing (raising) an exception from the CRUDs level and catch in on the Controller level. But if I understand correctly, exceptions in Elixir philosophy are more about unexpected errors that should be handled by this “Let it crash” way.
My question still is: is it normal and common way to write elixir code having this error checks (case/with) on every layer of the application?
I can provide some naive code example if my thoughts are not clear.
Most Liked
sezaru
I’m not sure if I follow you when you say you cannot redirect them all to the controller.
Let’s say you have a function CRUD.get that returns {:ok, value} or :error, reason} and that reason can be multiple types of errors.
Now let’s say you want to redirect the errors to the controller from your business logic and handle the :ok case, if you redirect something to the controller via this function return, you can simply do something like:
with {:ok, value} <- CRUD.get() do
# Do something with value
end
This will handle the :ok case and redirect all the other ones.
If you need to call a function to redirect it to the controller, you can do something like:
with {:ok, value} <- CRUD.get() do
# Do something with value
else
{:error, reason} -> Controller.redirect({:error, reason})
end
or
case CRUD.get() do
{:ok, value} ->
# Do something with value
{:error, reason} ->
Controller.redirect({:error, reason})
end
In all these cases you don’t need to have a case for each error tuple, you can simply pattern match all of them.
Now at the Controller, if you want to handle each one of the errors, then you will need to use case or function pattern match to handle it, but that would be the same with java handling the catch cases.
Doesn’t that solves the issue or am I missed the point entirely of what the real problem is in your case?
joaquinalcerro
You can also check this interesting post from @michalmuskala - Error Handling in Elixir Libraries | Michał Muskała
hauleth
I would say that it depends on the requirements and what kind of error is that:
- if there is reasonable way to do fallback, for example fetching data failed, but we can return cached result or something like that, then using ok/error tuple is ok
- if there is no reasonable way to fallback, for example there is no user in the DB for given ID, then I would throw and let
Plug.Exceptiondo it’s thing
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
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.
Practical resources that improve the lives of professional developers.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"