I’m not sure if I follow you when you say you cannot redirect them all to the controller.

Let’s say you have a function CRUD.get that returns {:ok, value} or :error, reason} and that reason can be multiple types of errors.

Now let’s say you want to redirect the errors to the controller from your business logic and handle the :ok case, if you redirect something to the controller via this function return, you can simply do something like:

with {:ok, value} <- CRUD.get() do
  # Do something with value
end

This will handle the :ok case and redirect all the other ones.

If you need to call a function to redirect it to the controller, you can do something like:

with {:ok, value} <- CRUD.get() do
  # Do something with value
else
  {:error, reason} -> Controller.redirect({:error, reason})
end

or

case  CRUD.get() do
 {:ok, value} ->
    # Do something with value

 {:error, reason} -> 
    Controller.redirect({:error, reason})
end

In all these cases you don’t need to have a case for each error tuple, you can simply pattern match all of them.

Now at the Controller, if you want to handle each one of the errors, then you will need to use case or function pattern match to handle it, but that would be the same with java handling the catch cases.

Doesn’t that solves the issue or am I missed the point entirely of what the real problem is in your case?

You can also check this interesting post from @michalmuskala - Error Handling in Elixir Libraries | Michał Muskała

I would say that it depends on the requirements and what kind of error is that:

• if there is reasonable way to do fallback, for example fetching data failed, but we can return cached result or something like that, then using ok/error tuple is ok
• if there is no reasonable way to fallback, for example there is no user in the DB for given ID, then I would throw and let Plug.Exception do it’s thing

How you’ve written it is how I would have probably done so also, but I can’t speak as a community luminary.

Related: Good and Bad Elixir which may give you a bit of peripheral insight at least.

Specifically “Don’t pipe results into the following function”, which you maybe could have used in surface logic, i.e:

def do_surface_logic() do
  DeepLogic.do_deep_logic()
  |> do_some_response_preparations()
end

def do_some_response_preparations({:ok, val}) ...
def do_some_response_preparations({:error, e}) ...

But as you say, it’s only really shuffling stuff around.

See also “Raise exceptions if you receive invalid data.” in the same article.

By it’s nature, the article has to be opinionated but it’s definitely worth reading once or twice, “know when to break the rules”, etc blah blah blah.

I think the existence of {:ok | :error} and the line “In practice, Elixir developers rarely use the try/rescue construct” in the getting started guide gives the impression that exceptions should be avoided in Elixir, but they exist to be used and is probably a few good blog posts waiting to be written re: navigating between them and tuples.

I personally am very inclined to force explicitness and use more verbosity to describe flows. When using with I normally resort to tagging the branches, but sometimes you do need to pass through the underlying returns from the failing branch. When writing API endpoints I’ve settled in just having a %Response{}/%Output{} struct with :errors, :notices, :payload fields that the frontend knows how to interpret - this approach requires you to do it almost from the beginning and be in control also of how the front-end interacts. It’s also not completely feasible for html pipelines, as you can have redirects and so on, but could probably be made so.

Controllers/channels call only into context functions, and these entry points in the contexts either return those payload structs, or they return normal results and I have a translation module/functions for the returns. Again, it’s more boilerplaty.

But the issue that I think deserves a bit more thought is not that raising exceptions in themselves is bad (outside of things that really require raising, like a db disconnect, or inaccessibility of a resource, or inside a loop/recursion that no longer makes sense, but usually there you use throw), when you look at the flow of a single entry point, it can usually look clearer and in a way less verbose. The problem comes when all your code base applies this style. Then it basically becomes a mine field because everything can raise somewhere and you’re left having to keep in mind every detail of all functions you’re calling and what those themselves are calling.

When I have too much time to think about this nonsense I imagine I would like to see a variation of with (a special form named weave or steps) that would look like this:

weave # notice the new line 
   [not_found: %User{} = user] <- Db.Repo.get(User, user_id),
   [not_authorized: true] <- Contexts.Authorization.is_authorized?(user, some_action),
   [changeset: {:ok, %User{} = new_user}] <- Contexts.Users.update(user, some_action)
do
   {:ok, user}
else
  [changeset: changeset] -> {:error, changeset}
  [{error, _}] -> {:error, error}
end

Perhaps it could even be that when the do block was ommitted it would pass the last value, without the keyword.

weave 
   [not_found: %User{} = user] <- Db.Repo.get(User, user_id),
   [not_authorized: true] <- Contexts.Authorization.is_authorized?(user, some_action),
   [changeset: {:ok, %User{} = new_user}] <- Contexts.Users.update(user, some_action)
else
  [changeset: changeset] -> {:error, changeset}
  [{error, _}] -> {:error, error}
end

This can be confusing the first time you encounter it (not_authorized: true) but afterwards it’s simple to understand.

Other option would be:

weave
  %User{} = user <- Db.Repo.get(User, user_id) -> :not_found,
  true <- Contexts.Authorization.is_authorized?(user, some_action) -> :not_authorized,
  {:ok, %User{} = new_user} <- Contexts.Users.update(user, some_action) -> :changeset
else
  [changeset: changeset] -> {:error, changeset}
  [{error, _}] -> {:error, error}
end