[erlang-questions] Best practices for handling invalid / unexpected messages

[Max Lapshin]

On Sun, May 15, 2011 at 7:36 PM, Daniel Dormont
<dan@REDACTED> wrote:
>
> On May 14, 2011, at 5:52 AM, Max Lapshin wrote:
>
>> I always make
>>
>> handle_call(Call, _From, State) ->
>>  {stop, {invalid_call, Call}, State}.
>>
>> as a last clause because it is a best way to know that _I_ haven't
>> validated call in function, that make gen_server:call
>
> Is this in a scenario where you're using an API? I think this is an area where I'm still confused about the Erlang design approach. Perhaps naively, I'd think that killing the entire gen_server process and losing its State is a pretty drastic response to an invalid call. I guess the real question is what's detecting the crash and what are they doing about it?

It _is_ a good idea to loose state, because your module should be designed so:


-module(rtmp_session).
-export([make_funcall/2]).

make_funcall(RTMPSession, RTMPFuncall) when is_pid(RTMPSession) ->
  is_valid_funcall(RTMPFuncall) orelse erlang:error(invalid_funcall),
  gen_server:call(RTMPSession, {make_funcall, RTMPFuncall}).


....
handle_call({make_funcall, ...


You should never expose that your process is gen_server to the
outside, because you may move some functionality from inside
gen_server to the caller process.

So it is a good idea to make all checks in caller process before
gen_server:call. That is why  wrong handle_call clause is a wrong
design of your calling chain and your gen_server cannot handle it
anymore.

So, it means, that your module have passed invalid call inside its
gen_server process. You can't and you should not handle this error,
because it is a design error,
not runtime.


If you silently throws away any messages and calls, you will have
raising amount of probems in your code.