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

[Jachym Holecek]

# Ciprian Dorin Craciun 2011-05-13:
> On Fri, May 13, 2011 at 22:59, Jachym Holecek <freza@REDACTED> wrote:
> > Yep, this is what I do:
> > [...]
> >  handle_info(_, State) ->
> >      {noreply, State}.
> >
> > It's similar with gen_fsm & custom processes.
> 
>     The main problem here is that it silently can "swallow"
> miscommunication bugs.

Yeah, but to be honest these don't really happen very often, so personally
I don't bother being defensive about them. If it became a big deal, I'd
probably just log unexpected messages in the catch-all branch.

> > 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.
> 
>     Indeed I'm speaking about an asymmetric relation; in general I'm
> speaking about a server and it's clients, the server can live if one
> client crashes, but none of the clients can without the server.
>
>     My problem is monitoring vs linking. Linking seems more
> "bullet-proof" than "monitoring"...

I will guess and say the problem you're pondering (fault propagation and
isolation) would be best solved at the level of supervision hierarchy
design instead of doing it manually.

But in general there's simply no silver bullet, ever (that's why I'm not
very keen on "best practices" and "design pattern" books) -- if you have
a reasonably minimal example application handy that demonstrates your
dilemma then we can discuss it in more detail. ;-)

BR,
	-- Jachym