Avoiding long `with` blocks

jonathan-scholbach

I find myself using a lot of very long with-statements. The functions in the with pipeline return {:ok, result} or some {:error, :error_type, additional_error_information} It could look somewhat like this:

with \
   {:ok, result_a} <- function_a(input),
   {:ok, result_b} <- function_b(result_a),
   {:ok, result_c} <- function_c(result_b),
   :ok <- some_validation_function_d(result_c)
do
  {:ok, result_c}
else
  {:error, :error_in_a} -> {:error, :internal_error}
  {:error, :another_error_in_a} -> {:error, :some_other_error}
  {:error, :error_in_b} -> {:error, :strange_error}
  {:error, :error_in_b, msg} -> {:error, :strange_error, msg}
  {:error, :error_in_c, msg} -> {:error, :internal_error}
  {:error, :validation_error, _msg} -> {:error, :validation_error, input, msg}
end

But sometimes I have blocks that are way longer even.

This looks like a legacy of thinking like an imperative programmer to me, using a a (not so) nicely nested catch-try tree.

I would like to find a way to make my pipeline functions perform an “early return”, so I would like to “break” the pipeline.

It should look something like this instead (not working pseudocode following):

input
|> {function_a(), error_handler_a}
|> {function_b(), error_handler_b}
|> {function_c(), error_handler_c}
|> {function_d(), error_handler_d}

Where each error_handler maps the error from the function to the correct error return I am using in this context. How do I do this best? I would be willing to write a macro (although I have no experience with this.) Another constraint: I do not want to use an external dependency for this, but be in full control of the code myself.

I am new to Elixir, and I can imagine that my idea of a solution does not make too much sense. If this is the case, what are other best practices to avoid the problem in the first place?

3 comments

#functional-programming #code-style #error-handling #with

1 1012 3

2021-10-07 14:51:44 UTC

First 3 of 3 Posts

stefanchrobot

One way to approach this is to avoid the else clause in with. This means that you need to introduce a somewhat generic error struct - it can be app-wide, or specific to some context. All the smaller functions will need to return the error struct on error or you’ll need to write local wrappers around them. So it would be something like this:

# Generic error.
defmodule MyApp.Error do
  defexception [:code, :message, :meta]

  @impl Exception
  def message(%__MODULE__{code: code, message: message, meta: meta}) do
    "Error (#{code}): #{message}, meta: #{inspect(meta)}"
  end

  def new(code, message, opts \\ []) do
    %__MODULE__{
      code: code,
      message: message,
      meta: opts[:meta] || %{}
    }
  end

  def auth_error() do
    new(:auth_error, "authorization error")
  end

  def validation_error(changeset) do
    new(:validation_error, "validation error", meta: changeset)
  end
end

# App logic.
defmodule MyApp.Foo do
  def bar(input) do
    with {:ok, result_a} <- function_a(input),
         {:ok, result_b} <- function_b(result_a),
         {:ok, result_c} <- function_c(result_b),
         :ok <- some_validation_function_d(result_c) do
      {:ok, result_c}
    end
  end

  # Example of wrapping.
  defp some_validation_function_d(result_c) do
    case run_validation(result_c) do
      :ok -> :ok
      {:error, changeset} -> {:error, MyApp.Error.validation_error(changeset)}
    end
  end
end

# Top-level code that runs the logic (e.g. controller, background job, etc.)
defmodule MyAppWeb.FooController do
  def create(conn, _params) do
    case MyApp.Foo.bar(params) do
      {:ok, result} -> #...
      {:error, %MyApp.Error{code: :validation_error}} -> # ...
    end
  end
end

mat-hek

Membrane Core Team

I believe the purpose of with is to separate the ‘happy’ path from error handling, so that one could easily see what the code is supposed to do and then dig into corner cases if necessary. While I see some similarity to try/catch, I don’t see what it has to do with imperative programming Anyway, I found myself ending up with long withs when I didn’t consider raising instead of returning :ok/:error, so I’d suggest to make sure that whenever you return an error, there is a potential need (or even possibility) to handle that error somewhere else. Otherwise it’s better to raise right away, to keep the code simpler, fail fast and make errors and stack traces more readable. That said, I don’t think that (reasonably) long withs are bad by themselves, but they have some quirks - withl is my attempt to solve them.

Post #2

Qqwy

TypeCheck Core Team

The pattern you describe does see some usage in some existing Elixir libraries. For instance, Ecto.Multi.

If the amount of successes/errors is large enough, such a pattern might make sense.
However, it might be better to split your with into multiple subfunctions that work at different levels of detail. This will make them shorter and the error-handling part of them more readable.
For instance, all the errors returned by function_a could have a similar shape. Then you’ll only need a single line in your else-block to forward all of these.
And even better would be to have the errors directly match what you want as output, rather than having to do a lot of wrapping/mapping of them.

There are also some libraries which remove some of the repetitive boilerplate of with-statements. (my contender: ‘Solution’)

Post #3

— All posts loaded —