I am new to Elixir, but I am quite confused. When I define @callback functions the module that is using the behavior is not producing error if that function is not implemented, it is just showing warning. I question would be what is the idea behind showing warning instead of throwing some error, thanks
I’m also confused about warning (instead of error), especially when we have
Maybe it happen historically… It would be awesome if error raised
I think a compilation error would be overkill. Behaviours are a way to establish explicit contracts. It’s a best practice, not a prerequisite for compilation.
If a callback module that implements a given behaviour doesn’t export all the functions and macros defined by that behaviour, the user will be notified through warnings during the compilation process (no errors will happen).
Well, contracts are worth nothing if they are not enforced. I actually find this compromise rather surprising.
I don’t have insight into the why the core team chose that route. You’d have to ask them. I appreciate the flexibility, personally.
I don’t know the rationale, however to turn warning into error yourself you can pass
--warnings-as-errors to mix compile, mix test and many other tasks.
Just my guess - not an official explanation.
I think the warning makes sense in the context of Elixir (or Erlang) being dynamically typed. If Elixir (and Erlang) was statically typed then an error would make sense.
Dynamically typed languages lend themselves to REPL-Driven-Development, i.e. you can build and exercise code in the absence of other functionality (to be added later) as long as your current runtime execution path doesn’t run off into the “other non-existent” parts of the code. With a statically typed language this is impossible - you would at least have to “stub out” all the other parts of the code - even if you currently do not plan to execute them at runtime (during development).
By only issuing a warning, you are free in development to write and run tests for parts of the behaviour that do not rely on that particular callback. This would be especially handy for behaviours with a relatively large number of callbacks. So the warning lets you get the first tests to run much more quickly - without necessarily having to sketch out the entire behaviour implementation first.
Now deploying code with these type of warnings (or ideally any warnings) into production would be questionable.