[erlang-questions] handling crash on db connect

Garrett Smith <>
Thu Jun 6 17:58:44 CEST 2013


Hi Paul,

Sorry I'm not used to seeing questions about my Redis bindings
graduate to the main list :)

On Thu, Jun 6, 2013 at 10:38 AM, Paul Rubin <> wrote:
> Jesper Louis Andersen wrote:
>
> Rewrite the driver? It makes sense to return some kind of error tuple in
> this case because it is expected behaviour that you cannot establish a
> connection. Then you can crash on
>
>   ok = redis:connect(…)

redis:connect is a wrapper for the process start_link. The return
value is standard for an OTP process: either {ok, Pid} or {error,
Reason}.

> Thanks.  It's odd that redis:connect() returns {ok, Connection} in the
> success case, which had me expecting it to return an error result in the
> failure case instead of crashing.
>
> I wonder if I could just be making some dumb error, and/or found a bug in
> the driver, rather than intended behavior.

Not a dumb error at all -- but neither a bug. This is by design and is
pretty common for OTP processes. In particular, risky code gets
executed in the context of the process (for the sake of proper
isolation) and calling processes need to trap exit to deal with
problems, or just let it all crash and get restarted by the
supervisor.

The question of how to handle connection problems can be tricky. I
typically bake this into a "connection handler" type process that
indeed traps exit and then figures out what to do -- other simply
let's the client process exit propagate up to the supervisor. I'll
typically have a retry logic that waits for a period of time after
failures, logging attempts, errors, etc.

This is obviously application specific (retry policies, logging, etc)
and IMO doesn't belong in the lower level redis client process.

Btw, this higher level process can also serve as a general wrapper to
the Redis client, exposing an application specific interface.

I can provide an example of this type of process -- or maybe something
like this would be appropriate as a utility within the library.

Garrett


More information about the erlang-questions mailing list