With/1 design patterns

yourpalal

When using with/1 to handle a bunch of matches and things that return {:ok, _} or :error or {:error, _} I often need to differentiate between errors, and I’ll wrap the individual matches in tuples, like this:

with(  
  {{:ok, shoes}, _} <- {get_shoes(outfit), :shoes},
  {{:ok, shirt}, _} <- {get_shirt(outfit), :shirt},
  {true, _} <- {shoes_match_shirt?(shoes, shirt), :matching}
) do
  {:ok, "service allowed"}
else
  {error, :shoes} ->
    {:error, "you forgot your shoes!"}
  _ ->
    :error
end

Mainly, I’m just curious how other people are handling things like this! What are you doing when you need to handle multiple error cases from with/1 ? One obvious solution is to give up on with/1 and use if or regular case statements or something like that.

Second, I’m open to any suggestions/criticism of the above code style.

12 comments

#with

0 1853 12

2018-08-07 13:29:49 UTC

First 10 of 12 Posts

idi527

If you care about specific errors for your conditions, you might be better off with case.

case get_shoes(outfit) do
  {:ok, shoes} -> 
    with
      {:ok, shirt} <- get_shirt(outfit),
      true <- shoes_match_shirt?(shoes, shirt) do
        {:ok, "service allowed"}
      else
        _ -> :error
      end

  _error ->
    {:error, "you forgot your shoes!"}
end

You can also try reversing the logic for the with expression thus making the successful path the “exception”. Might not be applicable here, though.

Post #1

hlx

I think you’re better of returning a more meaningful error from get_shoes/1

Example

{:error, {ShoesNotFound, "you forgot your shoes!"}}

# or

{:error, %ShoesNotFound{message: "you forgot your shoes!"}}

Post #2

peerreynders

The idiom is {:ok, value}, {:error, reason}

So the pattern match should focus on the contents of reason.

For example:

Process.monitor/1 will result in a general message of the format:

{:DOWN, ref, :process, object, reason}

where reason can take on values like :normal, :noproc or :noconnection, i.e. values that are highly distinct and imply their context. So it’s a good idea to follow the same practice with {:error, reason} tuples.

Post #3

yourpalal

Lots of good ideas from people I should mention that get_shoes/get_shirt are standins for code from the std. lib, or ecto or plug or whatever. They might be code I own, or maybe not.

The idea of improving the error messages is good, and in some cases could be done by changing what functions are used, too, eg. Map.get(params, :shoes, {:error, :no_shoes}) instead of Map.fetch(params, :shoes)

Post #4

yourpalal

Yes, that’s a good point. One of the things I like about with/1 is that it avoids nesting, but particularly if there are only one or two errors to handle, case could be the way to go (or if!).

with also lets me kind of replicate a pattern I like in imperative languages (eg. ruby):

shoes = get_shoes()
raise DressCodeError, "no shoes!" if shoes.nil?

shirt = get_shirt()
raise DressCodeError, "no shirt!" if shirt.nil?

This pattern of returning/raising as soon as possible also helps avoid a bunch of indentation, and means the function generally stays on the “happy path”.

Post #5

7stud

What does the left arrow do there? And where is the documentation for with/1?

Post #6

peerreynders

with/1

The precedent for the left arrow probably comes from for/1; see Pronouncing `<-` - #4 by peerreynders.

Post #7

7stud

Hmmm…I looked in the Kernel docs here:

and there is no with/1. Edit: Ah, I see. It’s listed under Kernel.SpecialForms.

And for anyone that cares, the <- operator is discussed on p. 39 of Programming Elixir 1.6 in the section titled “with and Pattern Matching”.

Post #8

idi527

with also lets me kind of replicate a pattern I like in imperative languages (eg. ruby):

Although not normally used for control flow, you can also throw and raise errors in elixir.

shoes = get_shoes()
is_nil(shoes) || raise(DressCodeError, "no shoes!")

# or

shirt = get_shirt()
is_nil(shirt) || throw({:error, {:dress_code, "no shirt!"}})

Post #9