giusdp
Refactor functions that can return different kind of errors
Hi all,
I was wondering on the best way to have a function that can return multiple errors. For example, I have something like this:
@spec run_some_work(atom(), Params.t()) ::
{:ok, Result.t()}
| {:error, :bad_params}
| {:error, :not_found}
| {:error, :no_workers}
| {:error, :worker_error}
The function can fail in different ways, and for each it has a different :error. in the @spec. I list them all so from the outside I can clearly see how to work with this function.
The problems that I’m having is that having functions with a big list of return types is cluttering my files, and that I have to update every spec if I add something new.
What’s your approach with functions that can give different errors? I was thinking about creating some sort of struct MyError, where the docs and specs would describe the possible errors it can contain, so in the function I would be just returning a single MyError struct.
Thanks in advance.
Marked As Solved
al2o3cr
On a purely mechanical level, you can solve these problems with @type - anywhere you can write a basic type, you can instead write a custom one:
@type work_errors :: {:error, :bad_params} | {:error, :not_found} | {:error, :no_workers} | {:error, :worker_error}
@spec run_some_work(...) :: {:ok, Result.t()} | work_errors
That addresses both the “this takes up a lot of space” issue as well as “this is an updating headache” issue.
HOWEVER
A better question would be who’s handling those errors, and how. If they’re doing:
case run_some_work(...) do
# etc
{:error, _} ->
yolo_try_it_again
end
then there’s not much value to maintaining detailed errors all the way up the stack. In that case, collapsing to a simpler error payload at a sensible boundary might make things clearer.
Finally, if the problem is likely to go away by just trying again (and if your data model tolerates it) you could consider “handling” errors like :no_workers by crashing.
Also Liked
dimitarvp
I’m sure somebody will show up and tell me I’m wrong but I frankly don’t care about exceptions in Elixir. And the whole other throw, raise and rescue stuff. I ignore them on purpose.
I have only reached for them when it was made clear to me that a worker cannot ever crash (and thus be auto-restarted) at which point I just said “okay, fair” and bullet-proofed it.
In every single other case, so 99.9%, I’ll reach for everything else but not exceptions / throws / raises. If something is that brittle and can crash periodically – but recovers by itself little later – then I’ll just wrap it in a GenServer and communicate through messages with it (so as the caller doesn’t crash right away). But if that keeps crashing then it’s best for your app to go down because you have an unrecoverable error, in which case exceptions wouldn’t help at all anyway.
TL;DR: there’s a very good reasoning behind the “let it crash” philosophy, provided you have taken some precautions (which the OTP either gives you by default or makes extremely easy for you to set up e.g. amount of process restarts before giving up, timeouts etc).
cmo
You can use defexception to define the error, which you can pass around as a struct or raise.
You can also define the list of errors as a @type if you’re repeating them.
cmo
You’re wrong! 
An exception is a struct, so you can be more specific about the cause and house more details/context than a simple atom. You don’t have to raise it.
For example, I have an external system that can return either a windows or app error code, which we turn into one of two exceptions with the code and message. I can easily distinguish between them and handle the different error cases.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
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.
Practical resources that improve the lives of professional developers.
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!"