Hello Ciprian, <div><br></div><div>IMHO </div><div>A) Define the "Caller" :</div><div> i believe you need to make a distinction between the boundaries of your system and the internals.</div><div><br></div><div>- On the boundaries, when other systems can feed data into yours, it's better to "validate" the inputs.</div>
<div>- Introduce client APIs for your gen_server, wrapping/abstracting the actual gen_server:call</div><div>- Do the validation in these APIs, so the crash will be in the client process scope.</div><div><br></div><div>For the gen_server callbacks itself (handle_call, handle_cast, handle_info), i would vote for letting it crash if something wrong got there, because</div>
<div>1) Makes your code cleaner, more neat and easier to debug</div><div>2) Doesn't hide bugs (Why a wrong request was made, and why it was not validated on the boundaries, also if the caller doesn't check replies, ..etc)</div>
<div><br></div><div>B) Other dependent processes : </div><div>It depends on your design, services provided by that gen_server and kind of state it keeps. In some cases, the processes needs to be restarted along with it (maybe to do initializations all over again), in other cases they don't need that. Define your case, and put the supervision tree that suites your needs.</div>
<div><br></div><div>I hope this helps</div><div><br><div class="gmail_quote">On Fri, May 13, 2011 at 8:46 PM, Ciprian Dorin Craciun <span dir="ltr"><<a href="mailto:ciprian.craciun@gmail.com">ciprian.craciun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">    Hello all!<br>
<br>
    Lately I've started programming a bit more seriously in Erlang,<br>
and after creating a few `gen_server` or `gen_fsm` components, I've<br>
started wondering what is the best way to handle unexpected or invalid<br>
requests / messages. (For example in `handle_call`, or `handle_info`<br>
or state handlers.) (By invalid requests I mean those that have the<br>
correct form (i.e. a tuple `{add, A, B}`) but invalid syntax (i.e. `A`<br>
is an atom); by unexpected messages I mean those that fail to even<br>
loosely match a valid pattern (i.e. `{some_unrecognized_operation, A,<br>
B}`.)<br>
<br>
    I think of three possibilities:<br>
    * reply back with an error:<br>
~~~~<br>
handle_call (Request, _Sender, State) -> {reply, {error,<br>
{invalid_request, Request}}, State}.<br>
~~~~<br>
    * exit with an error;<br>
~~~~<br>
handle_call (Request, _Sender, State) -> {stop, {error,<br>
{invalid_request, Request}}, State}.<br>
~~~~<br>
    * don't even create a special catch-all case and just let the<br>
process fail with `function_clause` error;<br>
<br>
    Now each of these have advantages or disadvantages:<br>
    * the first one is "polite" to the caller, letting him retry, but<br>
could lead to hidden bugs if the caller doesn't check the return term;<br>
    * the second one I think fits more the Erlang philosophy of<br>
"let-it-crash", but could lead to state loss (i.e. an ETS table);<br>
    * the last one I consider to be just rude as it doesn't give any<br>
information on why it failed;<br>
<br>
    Furthermore, let's say a process depends in his operation on<br>
another process, should it link the dependency process, should it<br>
monitor, or should it just fail on call?<br>
<br>
    So I ask the other Erlang developers how do they handle these situations?<br>
<br>
    Thanks,<br>
    Ciprian.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Best Regards,<br>- Ahmed Omar<div><a href="http://nl.linkedin.com/in/adiaa" target="_blank">http://nl.linkedin.com/in/adiaa</a></div><div>Follow me on twitter</div><div><a href="http://twitter.com/#!/spawn_think" target="_blank">@spawn_think</a></div>
<br>
</div>