Completely ignoring unexpected messages

[Alexander Gagarin]

Hi!

I use groups to organize connections between dynamically changing number of actors. And in my case it's perfectly fine if some actor joins the group and process only a subset of all messages types that are floating in this group (i.e. actor just filters messages it wants to listen to).

Unexpected messages response behavior is controlled via `set_default_handler()` and CAF provides several builtin policies: `reflect`, `reflect_and_quit`, `print_and_drop`, `drop`, and `skip`.
Seems that my choice is either `drop` or `skip`.

1. `drop` has the drawback that it send `unexpected_message` error back to sender and by default sender will terminate after that. So, I need to additionally set custom error handler for sender that will ignore `unexpected_message` errors. That works fine, but CAF runtime have to manage absolutely useless wall of  `unexpected message` errors. Am I right?

2. `skip` doesn't have that disadvantage and seems to be processed explicitly (completely omitting 'send response' stage). But! Seems that it saves skipped message in some cache (?) And this message will pop up again later?

Summarizing, what is the correct way to just completely drop/skip unexpected messages assuming that it's a perfectly valid situation by design?

Right now I decided to return `caf::none` from default handler. Is this feasible solution?

[Dominik Charousset]

You’re pretty much spot on. Skipping is not what you want, this feature enables actors to stash away messages for dealing with them later (usually by switching behaviors).

I’m not entirely sure what happens if you return ‘none’, though. You are probably constructing a caf::error with it. The best thing to do when completely dropping input is probably to return a default-constructed message form the default handler. This gets treated in the same way as a message handler returning `void`.

Dominik

[Alexander Gagarin]

Thanks for the info, Dominik!

I’m not entirely sure what happens if you return ‘none’, though. You are probably constructing a caf::error with it.

It seems that returning `none` will have the same effect as constructing empty `message`, because the latter has a noop constructor accepting `none`.

`result<message>` constructor, in turn, must detect this and effectively call `make_message(message(none))`.

I'll check it out after removing custom error handler from actors =)