In a with case, with many operations, how can i individually handle errors?

Match on the reason. If though all of them simply return the same reason, you can only wrap your stuff in extra tuples, eg (but untested as on mobile): with {:fetch_data, {:ok, data}} <- {:fetch_data, fetch_data(stuff)} do data else {:fetch_data, :error} -> {:error, :fetch_data_failed} end

Damm, i was thinking in this exactly solution, but it just seems so verbose. Take this example: with {:parse_limit, {:ok, limit}} <- {:parse_limit, parse_limit(request)}, {:parse_offset, {:ok, offset}} <- {:parse_offset, parse_offset(request)}, {:parse_filters, {:ok, filters}} <- {:parse_…

[image] pmjoe: how can i access the limit and offset? By adding them to the tuple.

I would suggest for you change each individual parse_ function to already return the error in the format you desire. Your code should look like this: with {:ok, limit} <- parse_limit(request), {:ok, offset} <- parse_offset(request, offset), {:ok, filters} <- parse_filters(request, limit, …

But the thing is, maybe, each error can have a individual treatment. Parsing limit, offset and filters, always will return a 4XX HTTP error to the client, as the request is invalid. A repository error, on the other side, will return a 5XX. In this case, the only way is to tag the errors like @NobbZ …

[image] pmjoe: But the thing is, maybe, each error can have a individual treatment. Scott Wlaschin: Use Functions! ... with {:ok, limit} <- parse_limit(request), {:ok, offset} <- parse_offset(request, limit), {:ok, filters} <- parse_filters(request, limit, offset) do # s…

Yep, this is it, you nailed it. I’m still grasping with Elixir, but this looks very good.

A further step you can take is to create an error struct, which might implement the Exception behavior. One big benefit of using structs over tuples for the error is you can add or remove data from a struct easier than you can a tuple (it won’t change the shape for pattern matching). I generally t…

[image] mischov: One big benefit of using structs over tuples for the error is you can add or remove data from a struct easier than you can a tuple If it is decoupling you’re after, the reason in {:error, reason} should be entirely opaque to the client of the module (which issued the error) -…