Penanganan Kesalahan yang Tangguh

Erlang is renowned for its fault tolerance. This isn't achieved by preventing all errors, but by expecting them and designing systems that can recover gracefully. We embrace the idea of 'let it crash' where appropriate, allowing supervisors to handle failures.

For errors that occur within a single process, Erlang provides the try...catch construct. This is useful for handling expected, localized issues like invalid function arguments, file not found errors, or custom application-specific exceptions.

It works similarly to exception handling in other languages, but it's less common for handling failures between different processes.

Let's see try...catch in a simple calculation. If an error happens, we can catch it and provide a fallback or log it. Notice how we match on error:badarith for a division-by-zero.

Erlang's try...catch allows matching on different types of exceptions:

• throw: For expected conditions, often used to jump out of deep function calls.
• exit: When a process terminates (e.g., exit(Reason)).
• error: For unexpected runtime issues (e.g., division by zero, undefined function calls).

Each type can be caught and handled differently.

Beyond `try...catch` for internal errors, Erlang processes communicate their termination using exit signals. When a process dies (either gracefully or due to an error), it sends an exit signal to all processes it's linked to.

This mechanism is fundamental for building fault-tolerant systems in Erlang.

By default, if two processes are linked and one terminates with an exit signal (other than normal), the other linked process will also terminate with the same reason. This is Erlang's 'let it crash' philosophy in action.

This propagation allows supervisors to detect and restart entire sub-systems, ensuring failures don't leave lingering, inconsistent state.

Sometimes, a process needs to handle the exit of a linked process instead of crashing itself. This is achieved by "trapping exits". A process can set its trap_exit flag to true.

When trap_exit is true, exit signals from linked processes are converted into messages that are sent to the trapping process's mailbox.

This example shows a 'parent' process linking to a 'worker'. The parent sets trap_exit to true. When the worker crashes, the parent doesn't crash but receives an {'EXIT', Pid, Reason} message, which it can then process.

When should you trap exits versus letting them crash?

• Let it Crash (default): Use when a failure in one process means the whole component is compromised. Supervisors will handle the restart logic.
• Trap Exits: Use when a process needs to clean up resources, log the event, or attempt recovery from a linked process's failure without itself dying. This is often used by supervisors themselves.

Consider a scenario where process_A is linked to process_B. process_B crashes with reason error_condition.

We've explored key Erlang error handling strategies:

• try...catch for localized, internal exceptions within a single process.
• Exit signals as the primary mechanism for inter-process failure notification via links.
• Trapping exits using process_flag(trap_exit, true) to convert exit signals from linked processes into messages, allowing a process to react to a linked process's termination without crashing itself.

Understanding these mechanisms is crucial for building resilient, fault-tolerant Erlang systems.