[lostcolony]

So, just to point out, the quote you're referencing is about the diagram, not the code. That is, the expected use case of the dog is undefined in that case; what the code does is thus undefined, and up to the implementor. It COULD crash. Or it could be handled. Or the message could just sit in the mailbox unanswered (messages that match no case clauses sit in the mailbox because the code may at a later date be able to handle such a message; see below). It's up to you.

We even see an example of that in the code. All those pattern matches with _ in them are the 'default' handling, the "it matched nothing else so match here and handle it". If it matched part of the receive clause, but that was not coded to handle that kind of message (your guard was insufficient), then it could crash (eg: receive {event, Pid} -> Pid ! blah, but you send the message {event, "stuff"}, would crash, since you can't send an event to a string).

That's actually a pattern I've noticed when it comes to Erlang vs Scala/Akka. A lot of the things that have special syntax in Scala/Akka, don't in Erlang, because they just flow naturally out of the language primitives. Another example is Akka's "become". In Erlang, you just call another function, that has a different receive block. And that's also why messages just sit in the mailbox if they match nothing; because the actor may enter a different receive block at a later time, that -can- respond to that kind of message.