A common pattern in this case is to have a get/x and a get!/x function (where x is the arity).

The unbanged version does return a tuple which first element is either :ok or :error while the second element is the result of the computation or the reason of failure (atom or string) depending on the first tuple.

The banged version on the other hand does either return the result of the computation or raises an exeption.

You can observe this pattern very often in the elixir standard library very often, an example of this is Map.fetch/2 and Map.fetch!/2.

The banged version is very often a simple wrapper around the unbanged one as in the following example:

@spec foo(any) :: {:ok, Foo.t} | {:error, String.t}
def foo(bar), do: bar |> do_the_magic

@spec foo!(any) :: Foo.t | no_return
def foo!(bar) do
  case foo(bar) do
    {:ok, result} -> result
    {:error, _}   -> raise FooError
  end
end

In the context of well designed supervision trees you probably do not even need to catch something raised, as well as you probably do not need to handle {:error, _} cases. Just try to match-assign the {:ok, _} and let the process die when it failed.

In the case you really have to handle the errors because of reasons that matter, do not raise, but use signaling tuples as in the unbanged functions, thrown axceptions do add some overhead and do add a significant runtime-cost.

Exceptions are to see exactly as this! An exception, a thing that might happen, but you do not consider it under normal circumstances. Use them only if you really want to fail, do not try to recover from them!

Generally it is exactly right. You should only handle returns from a function which you actually can handle. Please don’t program defensively.

You can see {:ok, res} = my_fun() as an assertion which should never fail. (or a failure you can’t do anything about anyway). And if it does fail, the supervisors make sure your application doesn’t crash.

If {error, reason} is something you need to handle in your business logic you deal with it with pattern matching and you should only deal with the errors you care about. Because it is part of business logic you have to deal with is so the “complexity” is unavoidable.

Don’t catch errors and log anywhere except the top level of your code. It is better to bubble up. Error messages should ideally be tuples of atoms with as much information as possible so that you clearly know which sort of errors to handle and which to ignore.

A nice “pattern” in erlang applications is to return atoms {:error, :some_error} and then have the module returning the error being able to format it into a readable string. This means you can bubble up the error message as a tuple and only the code doing the logging translate it to human readable format. It also means the module producing the error is able to give a meaningful message rather than the caller having to make something up.

case MyModule.my_fun() do
  {:ok, res} -> :working_good
  {:error, :some_error} -> {:error, :some_error}
end

and in top level handling code:

case x of
  {:error, reason} -> Logger.log(MyModule.format_error(reason))
end

It’s hard to be specific without knowing your exact use case, but since Elixir code run in processes, the most natural way to handle it is don’t. Let it crash, and let the monitoring process (Supervisor) restarts it. Catching exceptions (using try and rescue) is quite frowned upon I think.

However, it really depends on the nature of the error. Is it often or rare? Is it caused by misbehavior of the outside world, eg. network or hardware fails? The information could help to determine whether or not you need to write code to handle it.