Error Handling in Erlang

Erlang has three distinct classes of exception, all raised and caught through the same mechanism but carrying different intent: error/1 signals a genuine bug or unexpected condition (like a failed pattern match, which itself raises a {badmatch, Value} error, or a badarith, badarg, or function_clause error the runtime generates automatically), exit/1 signals that a process wants to terminate, whether normally or abnormally, and throw/1 is a non-local return mechanism used for ordinary control flow, such as escaping early from a deeply nested computation.

The try Expr of Pattern -> Body catch Class:Reason:Stacktrace -> Handler end construct is the modern (OTP 21+) way to both run code and handle any of the three exception classes it might raise, where Class is bound to error, exit, or throw so a single catch clause can distinguish which kind of exception occurred, and the optional Stacktrace variable, retrievable this way instead of the older erlang:get_stacktrace/0, lets you log or re-raise the original error context. The older, terser catch Expr operator is still common for simple cases: it evaluates Expr and, if an exception occurs, returns {'EXIT', Reason} for error and exit, or Reason directly for a throw, but because it collapses all three classes into ambiguous return shapes, catch is best reserved for situations where you genuinely don't care which kind of exception happened.

Erlang's most distinctive error-handling idea is 'let it crash': rather than wrapping every risky operation in defensive try...catch blocks, idiomatic Erlang code often lets a process simply die when it hits an unexpected condition, trusting a supervisor to notice the crash and restart the process into a known-good state. This works because Erlang processes are cheap and isolated, a crash in one process cannot corrupt another process's memory, and restarting a process from scratch is usually both simpler and more reliable than trying to enumerate every possible failure mode and defensively code around each one, especially for transient failures like a database connection blip that a fresh process will simply not encounter on its next attempt.

Supervision trees are how 'let it crash' becomes a real fault-tolerance strategy rather than just chaos: a process can link/1 to another so that if either one crashes abnormally, the linked process receives an exit signal too (which, by default, kills it in turn, propagating the failure), or it can set process_flag(trap_exit, true) to convert those exit signals into ordinary messages it can inspect and react to instead of dying, this is precisely the mechanism a supervisor behavior uses internally to notice when a child process has crashed and restart it according to a configured strategy (one_for_one, one_for_all, rest_for_one), without the programmer having to hand-roll any of that detection and restart logic themselves.