supervisor, behaviour(application), rebar3

[Papa Tana]

Hi,

I reassure you, "Let it crash" is just for the purpose to see the
magic of supervisor to restart my server automatically.
In real life, nobody would like his server to restart all the time.

I have read these websites before asking here, and I add this one
which is really useful as well to help for "understand parameters":

http://erlang.org/doc/design_principles/sup_princ.html

For those beginners like me who appreciates getting started from
examples, someone SOLVED my Hello World OTP question here (hope it
helps!)

htps://stackoverflow.com/questions/62984561/rebar3-supervisor-behaviourapplication/62986203#62986203

Thanks,
Have a nice day guys,
Best Regards,


2020-07-20 11:59 UTC+03:00, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED>:
> 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.
>