<div>How expensive is the state of the process to re-create? If it's super expensive, "let it crash" may not be the right choice.</div><div>Then again, if the reason you crash is that the state has gotten somehow corrupted, then crashing might be the only way to "clean it out."</div>
<div>And, on the third hand, when you've sufficiently hardened your application so that remote connection action cannot disturb it in unintended ways, no matter what crap gets thrown at it, then "let it crash" doesn't matter, because you won't crash anyway :-)</div>
<div> </div><div>Really, I find crash-and-restart to be fine for things that really only happens once in a blue moon. For anything that's a little more common -- unexpected remote connection disconnect, bad input data or unexpected message sequencing, for example, those really are design goals of the system. If all that crashes is the connection of the badly behaving user, then that's a fine way to disconnect that user. If it's further into the core of the application, perhaps not so.</div>
<div> </div><div>Sincerely,</div><div> </div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br></div><div class="gmail_quote">On Sat, Sep 3, 2011 at 6:31 PM, Daniel Dormont <span dir="ltr"><<a href="mailto:dan@greywallsoftware.com">dan@greywallsoftware.com</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
This was an earlier thread of mine that inspired a new question.<br>
<br>
As the months go by I'm getting more comfortable with "let it crash"<br>
as an idea and seeing its benefits. But it occurs to me: surely there<br>
are exceptions. Or rather: in order for "let it crash" to work at one<br>
level of abstraction or functionality, there must be actual<br>
crash-handling code at a level beneath it. In Erlang, this seems to<br>
often involve letting individual processes crash and their supervisors<br>
react accordingly. But perhaps that's not always the right answer. So<br>
my question is:<br>
<br>
When is "catch" the right tool for the job? In the example below,<br>
Ejabberd's "hooks" handlers use catch when calling functions in<br>
foreign modules that are (probably) not critical path to whatever it's<br>
doing. That seems like a pretty decent case to me. Would you agree?<br>
What are some cases common in Erlang where exceptions need to be<br>
caught and handled (or ignored) within a single process?<br>
<br>
dan<br>
<br>
On Fri, Apr 22, 2011 at 1:30 PM, Per Melin <<a href="mailto:per.melin@gmail.com">per.melin@gmail.com</a>> wrote:<br>
> On Fri, Apr 22, 2011 at 4:32 PM, Daniel Dormont<br>
> <<a href="mailto:dan@greywallsoftware.com">dan@greywallsoftware.com</a>> wrote:<br>
>> It also occurs to me that switching to gen_server would offer another advantage in that it would be easy to recover from crashes in my own code. If I were not to do that though, is the recommended practice just to put a 'catch' call around code that might break?<br>

><br>
> I don't have enough context, but it sounds absolutely unnecessary to<br>
> create a gen_server for this.<br>
><br>
> I would consider it ejabberd's responsibility to handle any crashes in<br>
> your code. They have asked you for a callback function and they must<br>
> consider that it may break. And they are in a better position than you<br>
> to know how to proceed from a crash here. I did have a look in<br>
> ejabberd_hooks and they do catch exits from your function. Let it<br>
> crash.<br>
><br>
> I'm hesitant to touch the question of what is recommended practice<br>
> since this is the kind of thread where Dr Richard O'Keefe usually<br>
> comments after a while and turns everyone that posted before him into<br>
> fools.<br>
><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br>