An exit is a BEAM runtime event used to terminate a process deliberately or report that another process has terminated. Its reason is an arbitrary Elixir term, allowing observers to identify why termination occurred. section 8.1.1 section 8.2.1
Links turn termination into a fault-propagation mechanism. A linked process receives an exit signal containing the terminated process’s PID and reason; unless the reason is :normal, the receiver terminates by default. section 8.2.1
Production behavior depends on how processes receive and handle exit notifications:
- Create a bidirectional link with Process.link/1 or spawn_link/1; linked crashes can spread transitively through a process tree. section 8.2.1
- Trap exits with Process.flag(:trap_exit, true) to receive {:EXIT, pid, reason} messages instead of terminating automatically. section 8.2.1
- Use monitors when notification should be unidirectional and nonfatal; a monitored process produces a {:DOWN, reference, :process, pid, reason} message. section 8.2.2
- Place workers directly under a supervisor when links would make recovery too coarse; supervision can restart affected workers separately. section 9.1.1 section 8.4
Separating database and cache failures
A supervisor can start Todo.Database and Todo.Cache as separate children with strategy: :one_for_one. Killing the database process then restarts its database workers without restarting the cache. section 9.1.1
Listing 9.1 Supervising database server (supervise_database/lib/todo/system.ex)
defmodule Todo.System do
def start_link do
Supervisor.start_link(
[
Todo.Database, #1
Todo.Cache
],
strategy: :one_for_one
)
end
end
Inspect the supervisor child specification that separates database and cache processes; pair it with the restart output showing the recovery boundary. section 9.1.1
