[erlang-questions] Try-catch-after considered harmful.

[David Welton]

I'm not going to disagree with you, but take the opportunity to
encourage educators such as yourself to go a few steps beyond "letting
it crash" from time to time.

For instance, there are a lot of situations where you do not want your
application to fall over because some component, such as a database is
unavailable.  There are various "circuit breakers" that can help in
this situation, but they are not widely known:
https://github.com/jlouis/fuse - these should be in books, or maybe
even a gen_*something* of their own within OTP.

It's something I've struggled with in a system I'm involved with. For
instance, there's a GUI, and Erlang code it talks with.  The Erlang
code it talks with should be about the last thing to go down in the
system.  Indeed, it really shouldn't ever go down even if other bits
and pieces are flopping around on the floor like fish out of water, as
they restart their allotted restarts and then crash stuff higher up
the chain.  The GUI communication code should just calmly make note of
the fact that various other subsystems are not functional, and thus
the system as a whole is not functional, and let the user decide what
to do, which might involve running some diagnostics, calling the
service department to read out a somewhat-intelligible error message
(no stack traces with 'nomatch':
http://joearms.github.io/2013/04/28/Fail-fast-noisely-and-politely.html
) , or in the case of an IT pro, rebooting the machine and seeing what
happens.

We mostly have things figured out at this point, but I think it's an
area where Erlang could use some more documentation and examples.

This is a good article, by the way:
http://jlouisramblings.blogspot.it/2010/11/on-erlang-state-and-crashes.html

Thank you
-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/