<div dir="ltr"><font color="#000000"><span style="background-color:rgb(255,255,255)">Actually, I think we're very much on the same page here: I really meant it when I said "<font face="arial, sans-serif">crash for anything that breaks the contract" -- if your environment requires to take into account stray messages, then by all means take care of them. </font></span><span style="font-family:arial,sans-serif">In closed enterprise software systems, your contract often is much(!) tighter and cracking down on stray messages is usually highly desirable.</span></font><div>
<div><span style="background-color:rgb(255,255,255)"><font color="#000000"><font face="arial, sans-serif"><br></font></font></span></div><div><span style="background-color:rgb(255,255,255)"><font color="#000000"><font face="arial, sans-serif">If SSL spams my inbox I certainly want to know where it comes from, whether it has potential to clog up a process, needs attention, etc. and if I figure it's safe to discard this kind of message, then make a deliberate decision to do so. However, discarding all unexpected message because of this might be less than ideal.</font></font></span><div>
<br></div><div class="gmail_extra"><font color="#000000">-fl.</font></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 6, 2014 at 10:43 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I do not think "making it easy for anyone with access to mess up your system when inspecting" is a matter of taste? If I have to fear breaking everything every time I'm trying to look for data to fix a bug, I'll just pack my things and leave, I don't want that kind of stress.<br>

<br>
You're also making your system less stable if you run misbehaving third party code. And by third party, I include OTP's code. For example a while back the ssl application sent a harmless message to the accepting process under certain conditions, do you really want to crash in cases like this?<br>

<br>
"Let it crash" is great, but it's not the solution to everything.<div class=""><br>
<br>
On 08/06/2014 06:48 PM, Florian Waas wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
Matter of taste. If you like designs where unidentified messages<br>
circulate in your system and endless debugging sessions for race<br>
conditions, missed messaged, deadlocks etc. is your thing, ignoring<br>
messages is cool.<br>
<br>
If you're not good at this type of debugging or simple don't have the<br>
time for it consider tightening your design and eliminate any kind of<br>
slack from the system, then crash for anything that breaks the contract.<br>
<br>
-fl.<br>
<br>
<br>
<br>
On Wed, Aug 6, 2014 at 9:07 AM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div class="">
<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
<br>
    On 08/06/2014 04:55 PM, Peer Stritzinger wrote:<br>
<br>
        1. log the messages<br>
<br>
<br>
    For the few processes that can receive more than<br>
    calls/casts/monitors/exits I want to know what's being dropped in<br>
    case it's something important.<br>
<br>
<br>
        3. Ignore them without trace?<br>
<br>
<br>
    For everything else, which is the majority of the processes.<br>
<br>
    *Never* crash. Because if you do, then you can easily mess up your<br>
    system through the shell (like using sys:get_state on a normal<br>
    process, kaboom).<br>
<br>
    --<br>
    Loïc Hoguin<br>
    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
<br></div>
    ______________________________<u></u>___________________<br>
    erlang-questions mailing list<br>
    <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
    <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
    <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
</blockquote><div class=""><div class="h5">
<br>
-- <br>
Loïc Hoguin<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</div></div></blockquote></div><br></div></div></div></div>