No easy answer:<br><br>During development:<br><br>    Crash loudly - print lots of information about why you crashed<br>    do init:stop() or erlang:halt() *force* the programmer to fix the code<br><br>During production<br>
<br>    Crash silently - put lots of error in the log and send rude email to programmer<br>    if you can recover do so. If you cannot recover tell the user as politely as possible.<br>    *never* present the user with internal error message (this is most unprofessional)<br>
<br>What you do with an error thus depends upon the context where it occurs - basically<br>tell the programmer the truth and give them all the info needed to fix the error, while<br>apologizing to the end user ... send an email to the project manager telling the code<br>
is broken if you want the programmer to fix it :-)<br><br>/Joe<br><br><br><br><div class="gmail_quote">On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek <span dir="ltr"><<a href="mailto:freza@circlewave.net">freza@circlewave.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"># Ciprian Dorin Craciun 2011-05-13:<br>
<div class="im">>     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>
</div>> requests / messages. [...]<br>
<div class="im">><br>
>     I think of three possibilities:<br>
>     * reply back with an error:<br>
<br>
</div>Yep, this is what I do:<br>
<br>
  handle_call(_, _, State) -><br>
      {reply, {error, bad_request}, State}.<br>
<br>
  handle_info(_, State) -><br>
      {noreply, State}.<br>
<br>
It's similar with gen_fsm & custom processes.<br>
<div class="im"><br>
>     Now each of these have advantages or disadvantages:<br>
><br>
>     * the first one is "polite" to the caller, letting him retry,<br>
>       but could lead to hidden bugs if the caller doesn't check<br>
>       the return term;<br>
<br>
</div>It also helps forward-compatibility in presence of hot code upgrades.<br>
<div class="im"><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>
</div>Depends on how tightly they're bound together. Linking them means "one<br>
can't live without the other even for a second", monitoring means "one<br>
is vaguely interested if the other is still alive" (often to clean up<br>
some mess when the other dies), fail on call means "ok, I need you to<br>
handle my request now, but generally I don't really care about you".<br>
<br>
The last option is by far the most common, the other two are employed<br>
tactically in cases where it matters.<br>
<br>
HTH,<br>
<font color="#888888">        -- Jachym<br>
</font><div><div></div><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br>