Let me reformulate this so it is crystal clear. “Using exceptions to handle edge cases is not the way to go”.
As for minority, let’s stay educated and not generalise based on some subjective experience.
D4no0
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_fallback while already having means of handling exceptions.
4
adamu
My understanding (albeit potentially flawed) is that there are three methods for handling errors, and two places for defining the error response in Phoenix:
- Return an
:errortuple in the controller and use the fallback controller, as @D4no0 mentioned. Unfortunately, this is not helpful for you, as you’re dealing with a raisedEcto.NoResultsError. - Handle the exception one level up in the router using
Plug.ErrorHander, as @tfwright mentioned. However, I believe that this is more designed for handling side effects, as the error is reraised to be handled by point 3 below. - Use the error view. Plug wraps up all exceptions that occur during the request/response, and these are caught by Phoenix in the Endpoint
, which then renders a special error view. You can customise this to return the JSON response you like - I think this is the best solution. See the documentation.
2
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
2