Absolutely agree! I can’t recall a single time I didn’t write the catch-all handle_info. In contrast, I don’t think I ever wrote catch-all for handle_cast and handle_call.
sasajuric
Author of Elixir In Action
5
fishcakez
Ecto Core Team
I disagree with the consensus here. I don’t think there should be a catch all clause by default. I would like the handle_info/2 to crash in the default implementation just like handle_call/3 and handle_cast/2. Rather an explanation is required why you need the catch all - but if there is a catch all you must log. The reason we don’t crash by default in handle_info/2 is because we used to silently ignore it and didn’t log (there wasn’t a Logger).
Messages that come to handle_info/2 are likely from actions triggered by the process itself. For example monitor or port messages. In these situations you may want to disregard unhandled messages for old ports/monitors. However if the process is receiving monitor messages and the handle_info/2 clause catches all of :DOWN I would not write the clause because not expecting other messages. It would be overly defensive programming and there is a bug so want to crash.
2
hubertlepicki
The one thing I still wanted to point out is that since Eliixr 1.4, the default catch-all clause will be doing the logging. And I think @fishcakez you were the one who put that stuff in ;).
https://github.com/elixir-lang/elixir/commit/82cd54bcae43baed76bb826b0b989cea5c84830b
My point is, the behavior where you have a GenServer, you use it in the project. And then you decide to catch a message since you expect one. And this change in behavior causes you to discover a bugs that you did have already but messages were ignored. I just think it’s inconsistent.
Any ideas why the default implementation is not crashing GenServer?
1
fishcakez
Ecto Core Team
It would be too big a change to go from silently ignoring to crashing. Here is link to discussion: Redirecting to Google Groups
2
Qqwy
TypeCheck Core Team
So it is now a year and a half later…
I wonder: Would this kind of change be the sort of default that Elixir 2.0 would do differently?
0
michalmuskala
Given the handle_info callback was made optional in OTP 20 and logs when some unexpected message arrives, I think the path Elixir took was right.
2