[erlang-questions] Best practices for handling invalid / unexpected messages
Vance Shipley
vances@REDACTED
Sat May 14 07:40:50 CEST 2011
Ciprian,
If it's an API, either public or private, I find the sensible thing
to do is to have the caller fail with `badarg' just as they would do
when calling a function call with the wrong arguments.
Using an API module:
%% @spec (Pid::pid()) -> term()
%%
foo(Pid) when is_pid(Pid) ->
case gen_server:call(Pid, foo) of
{ok, Value} ->
Value;
{error, Reason} ->
exit(Reason)
end.
The callback would be:
handle_call(foo, From, State) ->
...
{reply, {ok, Foo}, State};
handle_call(_, From, State) ->
{reply, {error, badarg}, State}.
When the client calls gen_server:call/2 directly:
handle_call(foo, From, State) ->
...
{reply, Foo, State};
handle_call(_, {_, Pid}, State) ->
{reply, exit(Pid, badarg), State}.
On Fri, May 13, 2011 at 11:34:11PM +0300, Ciprian Dorin Craciun wrote:
} For example it would have been nice to have a return value like
} `{error, Reason, NewState}` from callbacks like `handle_call`, etc.;
} which depending on the running environment either "dispatches"
} `{reply, {error, Reason}, NewState}`, or `{stop, {error, Reason},
} NewState}`. But as such a solution doesn't exist I could just create
} three generic functions like `handle_call_error (Reason, NewState)`
} that is called from within `handle_call` in a tail position, thus
} achieving the same outcome.
}
} Any other ideas?
--
-Vance
More information about the erlang-questions
mailing list