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

[Joe Armstrong]

No easy answer:

During development:

    Crash loudly - print lots of information about why you crashed
    do init:stop() or erlang:halt() *force* the programmer to fix the code

During production

    Crash silently - put lots of error in the log and send rude email to
programmer
    if you can recover do so. If you cannot recover tell the user as
politely as possible.
    *never* present the user with internal error message (this is most
unprofessional)

What you do with an error thus depends upon the context where it occurs -
basically
tell the programmer the truth and give them all the info needed to fix the
error, while
apologizing to the end user ... send an email to the project manager telling
the code
is broken if you want the programmer to fix it :-)

/Joe



On Fri, May 13, 2011 at 9:59 PM, Jachym Holecek <freza@REDACTED>wrote:

> # Ciprian Dorin Craciun 2011-05-13:
> >     Lately I've started programming a bit more seriously in Erlang,
> > and after creating a few `gen_server` or `gen_fsm` components, I've
> > started wondering what is the best way to handle unexpected or invalid
> > requests / messages. [...]
> >
> >     I think of three possibilities:
> >     * reply back with an error:
>
> Yep, this is what I do:
>
>  handle_call(_, _, State) ->
>      {reply, {error, bad_request}, State}.
>
>  handle_info(_, State) ->
>      {noreply, State}.
>
> It's similar with gen_fsm & custom processes.
>
> >     Now each of these have advantages or disadvantages:
> >
> >     * the first one is "polite" to the caller, letting him retry,
> >       but could lead to hidden bugs if the caller doesn't check
> >       the return term;
>
> It also helps forward-compatibility in presence of hot code upgrades.
>
> >     Furthermore, let's say a process depends in his operation on
> > another process, should it link the dependency process, should it
> > monitor, or should it just fail on call?
>
> Depends on how tightly they're bound together. Linking them means "one
> can't live without the other even for a second", monitoring means "one
> is vaguely interested if the other is still alive" (often to clean up
> some mess when the other dies), fail on call means "ok, I need you to
> handle my request now, but generally I don't really care about you".
>
> The last option is by far the most common, the other two are employed
> tactically in cases where it matters.
>
> HTH,
>         -- Jachym
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110513/89a4a837/attachment.htm>