supervisor, behaviour(application), rebar3

[Jesper Louis Andersen]

On Sun, Jul 19, 2020 at 8:42 PM Papa Tana <papa.tana101@REDACTED> wrote:

> Now, Client is going to send a malformed data.
>
> I can write a case clause to match any message and simply ignore any
> malformed message.
>
>
I'd handle such a malformed message, usually by incrementing a counter when
it happens. Counting is relatively cheap and a good way to check if
something is wrong with a client.

The reason is that you are not really programming defensively in this case.
You already know that clients are likely (highly likely in fact) to send
malformed data. However, in the course of development, you might want to
keep the server simple and crash it upon facing errors.

The book suggestion Leonard wrote is an excellent one. For a quick run down:

- Your process must adhere to the OTP design principles. In practice this
can be achieved by making it into a gen_server.
- Once your process is an OTP-adhering process, you can arrange for it to
start a (worker-)child of a supervisor.
- The supervisor can be started as part of an application.
- Applications can be bundled into releases.

As your system grows, getting the Release -> Application -> Supervisor ->
Gen_Server hierarchy right becomes more and more important. But expect it
to take a bit of time to wrap your head around the OTP design ideas, since
that doesn't come easily. I suspect because those ideas are (were?) unique
to Erlang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200720/8be3174c/attachment.htm>