Error propagation in erlang - error-handling

Question

I have a bit of a conceptual question for error handling in erlang. Let's take, for example, some database call which returns either {ok, Result}, or {error, Err}. I have a library which wraps calls to this database so I can do some pre/post-processing. When this library calls the database, should it do
A) Crash hard on an error, otherwise return the result:
{ok, Result} = db:call(), postprocess(Result).
B) Crash hard on an error, otherwise return the wrapped result:
{ok, Result} = db:call(), {ok, postprocess(Result)}.
C) Actually handle the error and return it:
case db:call() of
{ok, Result} -> {ok, postprocess(Result)};
{error, Err} -> {error, Err}
end.
D) Something else
As a follow-up question, if I have another library which is calling this one, what error propagation should it use? My thinking is that a library should be consistent with its return values, I'm just not clear on how to decide what those should potentially be.

Answer 1

Well, it depends on type of error, and how it should be handled.
The B) seems to be least likely to be used anywhere. Since you can not return any bad value it makes no sense to wrap it in ok tuple.
The A) seems to be a good example for database-connection library. For example when you can expect problems with connection to your database. In general you would not want each time someone makes call to your code to anticipate such case, and restart the server. The erlang way would be to crash the user, and let it's supervisor restart it in good environment, and redo the request. This approach allows for happy path coding in user side, and strong separation between your application logic and code responsible for setting up (and restarting in same way) wright environment.
Similar results could be achieved with the C) approach (and clients matching only on ok tuple), but sticking to A) might give users more idea on what to expect from your side.
The C) handling could be used when the library client can handle your error in mining full way (from point of their logic). Good example might be proplist:get_value/2 where you are either able to pattern match on {Key, Value} response or you get one atom undefined. There is no ok atom returned, but Key is enough to find happy path. And usually clients of this code can easily handle undefined (which is kind of error) in a manner mining full to their logic. And of course they could just pattern match only on happy path, and let it crach. The idea is not handling errors just for sake of handling errors; you only implement your application case.
And one more note. In your C) example you only allow {error, Error} errors to be handled. If you would like to just pass all the errors this might be better approach:
case db:call() of
{ok, Result} ->
{ok, postprocess(Result)};
Else ->
Else
end.