whoiswentz
Sup guys.
I’m running into a problem and doubt, I need to create a Plug that runs after the Router, basically, I have a controller that throws an exception eg. Ecto.NoResultsError, I need to catch this error using a plug, handle it and return a JSON to the client.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
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
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
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!"
Marked As Solved- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tfwright
Why is the error reraising is undesirable for your use case? Your user is still going to get a json response (and the handlers allow that to be anything).
Also Liked
tfwright
Convenience I think would be the main reason. I assume your problem with Plug’s design is that generally it is a bad idea to use errors to control flow. But since we generally want to respond with a user friendly error even when an exception is not expected, this kind of logic seems required here. And once it’s necessary it seems too convenient not to take advantage of in cases where the exception is not strictly speaking unexpected but does not and could not require any special logic other than building the response, because the alternative is needing separate and explicit handling for every single API requirement (like parameter shape/format).
LostKobrakai
How did you try that? Because the http request should receive whatever you send as response in the handler. It shouldn’t matter that the error is reraised (e.g. to get properly logged).
See Phoenix.ConnTest — Phoenix v1.7.7 for testing those.
While the latter is a viable option the former is not generally true. Exceptions are the only way to handle errors from LV right now (via Plug.ErrorHandler) and phoenix itself for a long time didn’t have
action_fallbackwhile already having means of handling exceptions.tfwright
Are you using Phoenix? My memory was that this works out of the box.
But maybe take a look at Plug.ErrorHandler — Plug v1.20.2
Last Post!
LostKobrakai
Phoenix does a bit more, but conceptionally it works exactly the same as
Plug.ErrorHandler. It also reraises errors: phoenix/lib/phoenix/endpoint/render_errors.ex at 246ca7726e14ed94d3d878838cbd6add5a0df3e9 · phoenixframework/phoenix · GitHub