Easiest way to find the function that didn't match in the `with` statement

I have code like this (but bigger)

defmodule WithStacktrace do
  def hello do
    with {:ok, _value} <- {:ok, 1},
      {:ok, value} <- :wrong_shape do
      {:ok, value}
    else
      {:error, e} -> {:error, e}
    end
  end
end

This will raise:

** (WithClauseError) no with clause matching: :wrong_shape
    (with_stacktrace 0.1.0) lib/with_stacktrace.ex:3: WithStacktrace.hello/0

So, the stack trace points to the beginning of the with statement (line 3).
But the expression that matches neither its success case nor else block is at line 4 {:ok, value} <- :wrong_shape.

Let’s say my with expression consists of 10 such calls. How can I easiest check which one returns the :wrong_shape?

I am currently adding IO.inspects after each of those statements :smiley:

4 Likes

Relevant thread about with statements.

https://medium.com/very-big-things/towards-maintainable-elixir-the-anatomy-of-a-core-module-b7372009ca6d

Look at With chaining section of Sasa Juric article (I am unable to provide link to section as it has no hyperlink)

Kernel.SpecialForms — Elixir v1.16.0 - this is from elixir docs explain about else in with .

I am convinced with statements don’t need else most of the time. Are you trying to do some error recovery from else ?

if you have only one clause in else pattern matching error with {:error, e} and returning same, then its not needed. with will return error directly without need of else. I realised it very recently.

2 Likes

A couple of ideas.

Sometimes I’ve used tagged tuples. Something like:

with {:part1, {:ok, data}} <- {:part1, get_data()},
  {:part2, :ok} <- {:part2, process_data()} do

This allows matching the failed value in else and would show up in the WithClauseError too. But this can get very noisy very quickly.

Another option is to use a helper module like this (from ihumanable/icecreamcohen on Discord):

defmodule WithHelper do
  @spec op(atom(), any(), :strict | :permissive) :: any()
  def op(label, thing, mode \\ :strict) do
    if mode == :permissive do
      opt_permissive(label, thing)
    else
      op_strict(label, thing)
    end
  end

  defp opt_permissive(label, err) when err in [:error, false, nil], do: {label, err}
  defp opt_permissive(label, {:error, _} = err), do: {label, err}
  defp opt_permissive(_label, val), do: val

  defp op_strict(_label, val) when val in [:ok, true], do: val
  defp op_strict(_label, {:ok, _} = success), do: success
  defp op_strict(label, other), do: {label, other}
end

And now we can do it like this:

with {:ok, data} <- op(:part1, get_data()),
  :ok <- op(:part2, process_data()) do
    ...
else
  {:part1, error} -> do_something(error)
  {:part2, _error} -> halt()
end

This lessens the noise somewhat, assuming your functions stick to the ok-tuple standard.

6 Likes

You might also want to refer to this article by Chris Keathly.
He states:

If [you’re] in a situation where errors are a vital part of your functions control flow, then it’s best to keep all of the error handling in the calling function using case statements.

1 Like

Thanks for your answer!

I am doing debugging and I see that one of my functions does not conform to the expected spec. E.g. it might return just :error instead of {:error, reason} or just an atom e.g. :invalid_credentials instead of {:error, :invalid_credentials}.

Adding an else clause helps a little because I don’t pass that unexpected thing further down the line. But I think that is irrelevant. If I don’t have the else block, the entire with statement returns :wrong_shape and I am still back at square one.

How can I quickly discover which one of with statements did not match first?
I wish WithClauseError reported first expression that did not match instead of the line where the with keyword is :slight_smile:

2 Likes

Thanks for your response.

So, basically, there is no easy way to identify which function is failing without some kind of tagging.
When trying to understand code that is already written without tags, that doesn’t differ from putting an IO.inspect

I am not trying to handle multiple different errors. My assumption is that all functions in my with statement already return {:ok, value} | {:error | reason} but when I am wrong, I would really love to drill down on which one was that.

I agree with Crhis but I think I wasn’t clear with my question.

I don’t want to identify failing cases because I want to handle them differently.

In my scenario all functions should return {:ok, value} or {:error, reason} and that else clause is irrelevant.

But one of the functions does not conform to specification and returns something different which I’d like to fix. I encounter that scenario fairly often and each time it is a pain :stuck_out_tongue:

3 Likes

You can run debug session - if you can replicate the error.

Also if your code is not confirming to type spec - won’t the code analysis tools catch this ?

Debugging session is the way to go! Thank you!

I’ve never used it before and it looks awesome.

We are trying to introduce dialyzer right now, so things are still rough around the edges :slight_smile:

2 Likes

https://medium.com/very-big-things/towards-maintainable-elixir-the-anatomy-of-a-core-module-b7372009ca6d#85b8

2 Likes

Just dropping this awesome explanation here for with statement in elixir.

Either Monad in Elixir