<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Sun, Jul 19, 2020 at 8:42 PM Papa Tana <<a href="mailto:papa.tana101@gmail.com">papa.tana101@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Now, Client is going to send a malformed data.<br>
<br>
I can write a case clause to match any message and simply ignore any<br>
malformed message.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The book suggestion Leonard wrote is an excellent one. For a quick run down:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Your process must adhere to the OTP design principles. In practice this can be achieved by making it into a gen_server.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Once your process is an OTP-adhering process, you can arrange for it to start a (worker-)child of a supervisor.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- The supervisor can be started as part of an application.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Applications can be bundled into releases.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><br></div></div></div>