<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 25, 2014 at 2:28 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">
<br></div>
But why would you make the application crash if you need it to stay alive? If your DB driver application crashes because the DB is gone, something is *very* wrong with your DB driver application. I personally would stay the hell away from it.<br>

</blockquote><div><br></div><div>This is one of those things that as an erlang newbie I don't have a great intuition for yet.</div><div><br></div><div>On one hand I can imagine a properly implemented database application that, when the database goes away, crashes, is restarted appropriately, restores the connection or picks a new slave or whatever, etc., etc. -- and that design could be quite clean, free of ugly error handling code, and so on.</div>

<div><br></div><div>On the other hand, I can also envision a scenario under which that is a giant pain in the ass for clients of the database application, especially if there's any asynchronous messaging involved.</div>

<div><br></div><div>I know there's one subschool of the 'let it crash' mentality that appends '...until the error shows up in the log, and then update your code to handle it'.  And there's a subschool also which seems to draw a distinction between infrastructure applications (e.g., db drivers) and application-applications and applies 'let it crash' to each slightly differently.</div>

<div><br></div><div>In the end I know it's a pragmatic architectural decision which is heavily dependent on circumstances, but it would be interesting to hear from the old erlang dogs about, e.g., db drivers and other core underpinnings and what the battle-tested best practice is.</div>

<div><br></div><div>F.</div></div></div></div>