Skip to content

Instantly share code, notes, and snippets.

@myronmarston myronmarston/registry.ex
Last active Sep 23, 2016

Embed
What would you like to do?
Example of handling errors when using `GenServer.reply/2`
defmodule Registry do
# ...
def handle_call({:execute_against_shard, campaign_id, fun}, from, state) do
{shard_process, state} = find_or_create_shard(campaign_id, state)
ShardProcess.execute_and_reply(shard_process, fun, from)
{:noreply, state}
end
# ...
end
defmodule ShardProcess do
# ...
def handle_cast({:execute, fun, {client_pid, monitor_ref} = reply_to}, state) do
{result, state} = try do
execute_fun(fun, state)
rescue error ->
# This is a bit weird, but is necessary to ensure that the client that
# made the `GenServer.call` is properly notified of the failure and aborts
# immediately (instead of waiting on the timeout). `GenServer.call` sets
# a monitor and, after sending the message, waits for either a response
# or a `:DOWN` message matching the monitor ref. To cause its `receive`
# to match a message (and not just wait for the timeout), we have to send
# a `:DOWN` message matching what it is looking for.
#
# Normally this kind of thing is unnecessary because GenServers typically
# reply from `handle_call` (that is, the process which the client is monitoring)
# but in this case, the client is monitoring the registry but we are replying
# from a ShardProcess. So we have to do a non-standard thing here.
stacktrace = System.stacktrace()
send(client_pid, {:DOWN, monitor_ref, :process, self(), error})
reraise(error, stacktrace)
end
GenServer.reply(reply_to, result)
{:noreply, state}
end
end
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.