[Erlang Systems]

9 Errors and Error Handling

9.1 Terminology

Errors can roughly be divided into three different types:

A compile-time error, for example a syntax error, should not cause much trouble as it is caught by the compiler.

A logical error is when a program does not behave as intended, but does not crash. An example could be that nothing happens when a button in a graphical user interface is clicked.

A run-time error is when a crash occurs. An example could be when an operator is applied to arguments of the wrong type. The Erlang programming language has built-in features for handling of run-time errors.

When a run-time error occurs in Erlang, execution for the process which evaluated the erroneous expression is stopped. This is referred to as a failure, that execution or evaluation fails, or that the process fails, terminates or exits. Note that a process may terminate/exit for other reasons than a failure.

A process that terminates will emit an exit signal with an exit reason that says something about which error has occurred. Normally, some information about the error will be printed to the terminal.

9.2 Handling of Run-Time Errors in Erlang

9.2.1 Error Handling Within Processes

It is possible to prevent run-time errors from causing the process to terminate by using catch, see the Expressions chapter.

9.2.2 Error Handling Between Processes

Processes can monitor other processes and detect process terminations, see the Processes chapter.

9.3 Exit Reasons

When a run-time error occurs, the exit reason is a tuple {Reason,Stack}. Reason is an atom indicating the type of error:

Reason Type of error
badarg Argument is of wrong type.
badarith Argument is of wrong type in an arithmetic expression.
badmatch Evaluation of a match expression failed.
function_clause No matching function clause is found when evaluating a function call.
case_clause No matching branch is found when evaluating a case expression.
if_clause No true branch is found when evaluating an if expression.
undef The function cannot be found when evaluating a function call.
badfun There is something wrong with a fun.
badarity A fun is applied to the wrong number of arguments.
timeout_value The timeout value in a receive..after expression is evaluated to something else than an integer or infinity.
noproc Trying to link to a non-existing process.
nocatch Trying to evaluate a throw outside a catch.
system_limit A system limit has been reached. See Efficiency Guide for information about system limits.
Exit Reasons.

Stack is the stack of function calls being evaluated when the error occurred, given as a list of tuples {Module,Name,Arity} with the most recent function call first.


Copyright © 1991-2003 Ericsson Utvecklings AB