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!"}}

instead of Map.fetch(params, :shoes)

design patterns

Following Scott Wlaschin’s guidance - use functions!

def fetch_item(map, key) do
  case Map.fetch(map, key) do
    :error ->
      {:error, key}
    result ->
      result
  end
end

  ...

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

  ...

or

def fetch_item(map, key, msg) when is_binary(msg) do
  case Map.fetch(map, key) do
    :error ->
      {:error, msg}
    result ->
      result
  end
end

  ...

  with(  
    {:ok, shoes} <- fetch_item(outfit, :shoes, "you forgot your shoes!"),
    {:ok, shirt} <- fetch_item(outfit, :shirt, "you forgot your shirt!"),
    {true, _} <- {shoes_match_shirt?(shoes, shirt), :matching}
  ) do
    {:ok, "service allowed"}
  else
    {:error, msg} = msg_error when is_binary(msg) ->
      msg_error
    _ ->
      :error
  end

  ...

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.