Editing Erlang (programming language) (section)

=="Let it crash" coding style==

Erlang is designed with a mechanism that makes it easy for external processes to monitor for crashes (or hardware failures), rather than an in-process mechanism like [[exception handling]] used in many other programming languages. Crashes are reported like other messages, which is the only way processes can communicate with each other,<ref name=Verraes>{{Cite web|last=Verraes|first=Mathias|date=2014-12-09|title=Let It Crash|url=https://verraes.net/2014/12/erlang-let-it-crash/|access-date=2021-02-10|website=Mathias Verraes' Blog|language=en}}</ref> and subprocesses can be spawned cheaply (see [[#Concurrency and distribution orientation|below]]). The "let it crash" philosophy prefers that a process be completely restarted rather than trying to recover from a serious failure.<ref>{{Cite web|title=Reactive Design Patterns —|url=https://www.reactivedesignpatterns.com/patterns/let-it-crash.html|access-date=2021-02-10|website=www.reactivedesignpatterns.com}}</ref> Though it still requires handling of errors, this philosophy results in less code devoted to [[defensive programming]] where error-handling code is highly contextual and specific.<ref name=Verraes />

===Supervisor trees===
A typical Erlang application is written in the form of a supervisor tree.  This architecture is based on a hierarchy of processes in which the top level process is known as a "supervisor".  The supervisor then spawns multiple child processes that act either as workers or more, lower level supervisors.  Such hierarchies can exist to arbitrary depths and have proven to provide a highly scalable and fault-tolerant environment within which application functionality can be implemented.

Within a supervisor tree, all supervisor processes are responsible for managing the lifecycle of their child processes, and this includes handling situations in which those child processes crash.  Any process can become a supervisor by first spawning a child process, then calling <code>erlang:monitor/2</code> on that process.  If the monitored process then crashes, the supervisor will receive a message containing a tuple whose first member is the atom <code>'DOWN'</code>.  The supervisor is responsible firstly for listening for such messages and for taking the appropriate action to correct the error condition.