0

I am reading the docs and it says that when some error occurs the process terminates and the supervisor can restarted the crashed process. But I am thinking that why not use a try catch block to catch the errors without making the process kill itself? Is there a need for supervisors then?

  • Possible duplicate of [When to "let it crash" and when to defend the code in Erlang?](http://stackoverflow.com/questions/38835690/when-to-let-it-crash-and-when-to-defend-the-code-in-erlang) – A. Sarid Aug 14 '16 at 07:53
  • Take also a look at [Should I use try catch in Erlang or should I pass back an error token?](http://stackoverflow.com/questions/2273655/should-i-use-try-catch-in-erlang-or-should-i-pass-back-an-error-token) – A. Sarid Aug 14 '16 at 08:04
  • I am still not clear. If I have a divide by zero exception, why not catch it? –  Aug 14 '16 at 09:27
  • Have you read all answers in both posts? I really don't think I can add more. Dividing by zero is one specific case (that you may catch if that is what you wish), but what if the process crashed in a case you didn't expect? It is really up to you and your implementation. – A. Sarid Aug 14 '16 at 10:06
  • 1
    See [Joe Armstrong's PhD thesis (PDF)](http://erlang.org/download/armstrong_thesis_2003.pdf) for a detailed explanation. – Steve Vinoski Aug 14 '16 at 13:29
  • Thank you Steve. That papers makes it clear. In case of distributed programs monitors or supervisors makes more sense. When computer 1 fails computer 2 is notified. Similar philosophy is applied to processes also. –  Aug 14 '16 at 14:14

1 Answers1

0

Use a try catch or the like for things that are likely to happen and be recoverable. But for many things just letting the process crash will be the correct result and take far less code (remember your error handlers can have bugs too)

Zachary K
  • 3,205
  • 1
  • 29
  • 36