Strangely no one has mentioned structures yet? Are you guys not using them? Is that too much work for example?
OndrejValenta
cjbottaro
No. Since the previous case handles errors, I’m assuming the “fall through” or “catch all” case means success. ok is a var that matches anything and just returns it.
x = case {:ok, "foo"} do
:error -> {:error, "no good"}
ok -> ok
end
In that case, x will be {:ok, "foo"}.
1
cjbottaro
I only use structs when the error can possibly have tons of info, otherwise it’s just easier to match on {:error, atom}.
For example, I have a clustered Memcached client that supports multiget, multiset, etc. That definitely returns {:error, %Error{...}} because there is lots of info about what went wrong (connection error? which server? did some keys succeed? Which did, which didn’t?).
Off the top of my head HTTPoison and Xandra both do the whole {:error, %ComplexErrorStruct{...}} thing. Works great and makes sense since the errors contain lots of info.
0
al2o3cr
I can’t think of any return-value-specific guidance on structs - in general, they’re the right choice when:
- you have a lot of separate pieces of data that would make a tuple unwieldy
- the users of that data depend on specific keys, so a type more specific than
map()is useful
As @cjbottaro points out, HTTPoison is a good example of this; returning a giant tuple or a map from a function like request wouldn’t be ideal.
0
fmn
Just as a curiosity maybe - the pattern I am occasionally following is:
{<return code>, <returned data>, <error/exception>}, with instances of it being:
{:ok, data, nil}
{:err, nil, exception_or_error}
It was giving me sense of that, I don’t need to care much about types returned, and order of elements is everything, which is not really the case.
0
al2o3cr
What’s the benefit of having one element of the tuple always be nil?
It reminds me of Go’s result, err idiom, but that uses err == nil to signal :ok.
I could maybe see if being useful if you had a mixed list of OK / error results and wanted to get all the data (and nil on error) - you could spell it Enum.map(list_of_mixed_results, &elem(&1, 1))…
2
OndrejValenta
fmn
keeping length of a tuple same I guess 
length of a tuple and order of elements is part of its API, data model etc. - you could say.
^^^ OK, that part makes little to no sense. Please disregard it 
I get your point, it’s more of a curiosity than anything else - it would make sense only when both data and error can be returned at the same time.
0
msimonborg
{:ok, result} and {:error, error} are tagged tuples. The primary value of tagged tuples being for pattern matching, some people use them in with statements just to match on multiple else clauses, such as this example (of what not to do) from @keathley 's blog post Good and Bad Elixir
with {:service, {:ok, resp}} <- {:service, call_service(data)},
{:decode, {:ok, decoded}} <- {:decode, Jason.decode(resp)},
{:db, {:ok, result}} <- {:db, store_in_db(decoded)} do
:ok
else
{:service, {:error, error}} ->
# Do something with service error
{:decode, {:error, error}} ->
# Do something with json error
{:db, {:error, error}} ->
# Do something with db error
end
I think this is the (anti-)pattern @cmo was referring to, and something José Valim has also publicly discouraged.
1
cjbottaro
Ha! I used to do the same thing for the same reason. But then yeah, I noticed that it just makes pattern matching more cumbersome for no real reason.
And that’s the beauty of pattern matching, right? Matching
case foo do
{:ok, nil}
end
Is arguably just as easy (or harder?) than…
case foo do
:ok
end
1