xgeek116
Hello,
In my Phoenix application, my domain module will return a tuple {:error, reason} to the controller, I have 2 questions :
- What is the recommended value for the var “reason” ? Is it the error code atom (:not_found, :forbidden etc.) or the error message ?
- In the controller, which is better ? to raise the right exception (with the plug status) based on the error code or to render them ? is there a difference between handle error and raise the exception ?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #elixirconf-us
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
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!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cloudytoday
I think it’s highly personal and situational. My subjective opinion is that if you’re not planning to show the error reason to end-users and if no extra context is required, an atom will suffice. I also don’t like exceptions in general and prefer to deal with error values rather than all this runtime magic. Therefore any expected error is, for me, not exceptional.
xgeek116
thanks @cloudytoday
So how to return the error to the end user (I must include the reason indeed) ?
cloudytoday
Again, it absolutely depends on the context. Who is the end user, how much do they need to know, what could they do with this info, how could they recover from the error. In your example, you’re passing the error to the controller, so if the controller has absolutely no way of recovering from this error then you could indeed raise. Or, if it could recover, then you’d have to consider what extra info it will need to do so, and what info it will not need, and how it will handle this info. I don’t think there’s a general answer to this, really depends on the specific case.
Also, I like propagating the error as far as possible so that if there’s a need to raise, all raising happens from within some central point and not in random places (IMO, raising is just outside the responsibility of the “building blocks” functions – their job is to return either {:ok, result} or {:error, reason}).