[erlang-questions] using guards in gen_server

Attila Rajmund Nohl <>
Sun Aug 29 18:46:16 CEST 2010


I'd like to add one note: a badarg or function_clause error in a
handle_call function might be hard to understand, because there might
be many handle_call function clauses. So either crash in the API call
or put the application logic into a do_something() function called
from a handle_call and put the guard there (if possible).

2010/8/29, Robert Virding <>:
> It depends on where you want the error caught and what is to be done.
>
> If you put the guard in the API then the caller will crash, or if you
> add an extra clause return some for of error. I would most definitely
> let it crash as it a clear programming error if it happens.
>
> If you put the guard in the server then the server will crash or the
> error will have to be handled there. This doesn't seem right in this
> case but it does depend on what is right for the application.
>
> It all comes back to the central problem with errors: where are they
> to be detected and "handled". And this is very application dependent.
> I personally feel that type errors, like this one, should be caught as
> early as possible and generate and exception as they are usually
> caused by programming errors.
>
> Robert
>
> On 29 August 2010 11:20, Zvi <> wrote:
>> Hi,
>>
>> When writing gen_server, do you put validation guards in API functions
>> or in handle_call / cast or in both ? What's the convention?
>>
>> For example:
>>
>> send(Pid) when is_pid(Pid) ->
>>   gen_server:call(?SERVER, {send, Pid}).
>>
>> handle_call({send, Pid}, _From, _State) ->
>>   Resp = do_send(Pid),
>>   {reply,  Resp, State}.
>>
>> OR:
>>
>> send(Pid) ->
>>   gen_server:call(?SERVER, {send, Pid}).
>>
>> handle_call({send, Pid}, _From, _State) when is_pid(Pid) ->
>>   Resp = do_send(Pid),
>>   {reply,  Resp, State}.
>>
>> OR:
>>
>> send(Pid) when is_pid(Pid) ->
>>   gen_server:call(?SERVER, {send, Pid}).
>>
>> handle_call({send, Pid}, _From, _State) when is_pid(Pid) ->
>>   Resp = do_send(Pid),
>>   {reply,  Resp, State}.
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:
>>
>>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
>
>


More information about the erlang-questions mailing list