[erlang-questions] Poll: How do you handle spurious messages?

Fred Hebert mononcqc@REDACTED
Wed Aug 6 21:39:30 CEST 2014

I tend to go the log route. There isn't a super good reason, but the way
I think about it is a bit of probability.

When do I send messages to the wrong process? A few ideas are:

- Manual debugging
- Typoes
- A Refactoring gone bad
- Initial design got messed up
- Erroneous third-party code that doesn't come from my precise
  development right away.

Then the question is what are the consequences I want.

- Manual debugging: do nothing, I'm poking around
- Typoes: I have to know about these ASAP
- Refactoring gone bad: I have to know about these ASAP
- Initial design got messed up: Something has to be loud and bad
- Third party code: I want the third party to suffer.

For these reasons, I tend to take the following approach:

- In handle_call/3, I log the event with a string a bit like
  "mod=MYMOD at=handle_call warning=unexpected_call msg=~p" and then
  return `{noreply, State}` to force the caller to crash after a
  timeout. It's their fault, not mine.
- In other callbacks, just log similar messages, replacing
  at=handle_call with at=handle_cast|info and

I can, from time to time, look at logs for 'warning=unexpected_*' in
logs and see if something is going weird.

If it's something happening rarely, I'm gonna have traces, but without
the weird failures (unless it's a call). If it's something frequent,
bugs will either show themselves differently, the log volume will be
very high, and so on.

It tends to give me what I need given the circumstances. It's not always
as loud as I'd expect (except for calls, which is ideal), but it tends
to give me enough visibility for the occasional stray message, without
compromising service levels.


On 08/06, Peer Stritzinger wrote:
> Or in gen_server speak:  what goes into your catchall
>   handle_info(_Info, State) ->  ???
> Do you:
> 1. log the messages
> 2. count them e.g. with folsom or similar -> then what do you do with the
> counts?
> 3. Ignore them without trace?
> 4. Crash the server (gasp)?

More information about the erlang-questions mailing list