Tratamento robusto de erros
Implemente um tratamento estratégico de erros usando try/catch, sinais de saída e captura de saídas para gerenciar falhas de forma elegante.
Tratamento robusto de erros é uma aula grátis de Erlang OTP: Distributed & Fault-Tolerant Systems Programming no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Erlang OTP: Distributed & Fault-Tolerant Systems Programming, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
Erlang's Error Philosophy
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.
Catching Internal Errors
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.
`try...catch` in Action
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.
-module(calculator).
-export([safe_divide/2]).
safe_divide(A, B) ->
try A / B of
Result -> {ok, Result}
catch
error:badarith ->
{error, division_by_zero}
end.
% To run in shell:
% calculator:safe_divide(10, 2).
% calculator:safe_divide(10, 0).Matching Different Exceptions
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.
-module(exception_matcher).
-export([test_catch/1]).
test_catch(Val) ->
try
case Val of
throw_it -> throw(something_thrown);
exit_it -> exit(something_exited);
error_it -> 1 / 0;
_ -> "no error"
end
catch
throw:something_thrown -> {caught, thrown};
exit:something_exited -> {caught, exited};
error:badarith -> {caught, error_badarith};
_ -> {caught, unknown}
end.
% To run in shell:
% exception_matcher:test_catch(throw_it).
% exception_matcher:test_catch(exit_it).
% exception_matcher:test_catch(error_it).Exit Signals: Erlang's Core
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.
Links Propagate Exits
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.
Trapping Exits with `process_flag`
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.
Handling a Linked Process Exit
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.
-module(exit_trap_demo).
-export([start/0, worker/0]).
start() ->
ParentPid = self(),
WorkerPid = spawn_link(fun() -> worker() end),
process_flag(trap_exit, true), % Parent traps exits
io:format("Parent (~p) linked to Worker (~p)~n", [ParentPid, WorkerPid]),
receive
{'EXIT', WorkerPid, Reason} ->
io:format("Parent caught worker exit: ~p~n", [Reason]),
{worker_died, Reason}
after 5000 ->
io:format("Parent timed out waiting for worker exit.~n"),
timeout
end.
worker() ->
io:format("Worker (~p) starting...~n", [self()]),
timer:sleep(1000), % Do some work
exit(bad_calculation). % Worker crashes
% To run in shell:
% exit_trap_demo:start().Choosing Your Strategy
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.
Quick Check
Consider a scenario where process_A is linked to process_B. process_B crashes with reason error_condition.
Robust Error Handling Summary
We've explored key Erlang error handling strategies:
try...catchfor 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.
Perguntas Frequentes
A aula “Tratamento robusto de erros” é grátis?
Sim — o texto completo de “Tratamento robusto de erros” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Erlang OTP: Distributed & Fault-Tolerant Systems Programming, atualize para CoddyKit PRO. O curso de Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclui 4 aulas no total.
O que vou aprender em “Tratamento robusto de erros”?
Implemente um tratamento estratégico de erros usando try/catch, sinais de saída e captura de saídas para gerenciar falhas de forma elegante. Você pratica Erlang OTP: Distributed & Fault-Tolerant Systems Programming com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Erlang OTP: Distributed & Fault-Tolerant Systems Programming?
Nenhuma experiência prévia é necessária. Erlang OTP: Distributed & Fault-Tolerant Systems Programming no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.
Quanto tempo leva a aula “Tratamento robusto de erros”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Erlang OTP: Distributed & Fault-Tolerant Systems Programming?
Sim. Cada aula de Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Explicação sobre links e monitores
- Tratamento robusto de erros
- Design orientado ao princípio de falhar primeiro
- A Filosofia Let-It-Crash