Middleware like plug

Phoenix Forum Questions / Help
, ,
1

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.

2 Likes
2

Are you using Phoenix? My memory was that this works out of the box.

But maybe take a look at Plug.ErrorHandler — Plug v1.15.2

2 Likes
3

Yes, I’m using Phoenix

I already tried the Plug.ErrorHandler, but it re-raises the error as the documentation points

I need a solution to enrich the error message and return a JSON

4

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).

3 Likes
5

Raising an error is not the way you do things in elixir.

Instead of raising, you can return a tuple in the format {:error, :not_found} and handle it in a fallback controller.

6

Curious what you mean by this. Certainly runtime errors, and therefore error raising, is a feature of the language? Or maybe you just mean that raising an error in this case is a bad pattern? But Plug literally has built in support for this and Phoenix is configured to take advantage of it by default, so while opinions may differ it is certainly “the way you do things” for many people…

1 Like
7

It’s a feature to pass errors up to the parent process, why you would use it in this case is beyond my understanding.

8

I have a huge code base that some functions raise errors, I didn’t have a choice :frowning:

9

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).

4 Likes
10

My problem is in general related to using exceptions as flow, this is the same as using goto statements, error prone and totally unreadable.

You don’t want to respond to a user with a specific response when something unexpected happens, as this is a bug in the system, and the user doesn’t need to know the details, as you are potentially exposing a exploitation interface. In the case with not found, that is not a bug though, it is a case that should be handled appropriately and using a fallback controller in conjunction with a with statement is the most appropriate solution.

I don’t see how this is the case here, you just handle the error response coming from your controller:

def call(conn, {:error, :not_found}) do
    conn
    |> put_status(:not_found)
    |> put_view(MyErrorView)
    |> render(:"404")
  end
11

I didn’t intend to make this a debate about the merits of the approach. Again, I just wanted to point out that, unless I am greatly mistaken, your claim that using Plug.ErrorHandler for this is not “the Elixir way” is almost exactly opposite of the truth, it’s actually the default in Phoenix which I would say makes the most common approach. I don’t think it’s helpful to formulate minority opinions as if they are majority (which of course is not to say that your opinion must be wrong because it’s the minority).

12

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.

13

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 Likes
14

My understanding (albeit potentially flawed) is that there are three methods for handling errors, and two places for defining the error response in Phoenix:

  1. Return an :error tuple in the controller and use the fallback controller, as @D4no0 mentioned. Unfortunately, this is not helpful for you, as you’re dealing with a raised Ecto.NoResultsError.
  2. 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.
  3. Use the error view. Plug wraps up all exceptions that occur during the request/response, and these are caught by Phoenix in the Endpoint:magic_wand:, which then renders a special error view:magic_wand:. You can customise this to return the JSON response you like - I think this is the best solution. See the documentation.
2 Likes
15

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 Likes