Terminology
Errors can roughly be divided into four different types:
- Compile-time errors
- Logical errors
- Run-time errors
- Generated errors
A compile-time error, for example a syntax error, does 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 is that nothing happens when
a button in a graphical user interface is clicked.
A run-time error is when a crash occurs. An example is
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.
A run-time error can also be emulated by calling
erlang:error(Reason) or erlang:error(Reason, Args).
A run-time error is another name for an exception
of class error.
A generated error is when the code itself calls
exit/1 or throw/1. Notice that emulated run-time
errors are not denoted as generated errors here.
Generated errors are exceptions of classes exit and
throw.
When a run-time error or generated error occurs in Erlang,
execution for the process that 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. Notice that a process can
terminate/exit for other reasons than a failure.
A process that terminates emits an exit signal with
an exit reason that says something about which error
has occurred. Normally, some information about the error is
printed to the terminal.
Exceptions
Exceptions are run-time errors or generated errors and
are of three different classes, with different origins. The
try expression
can distinguish between the different classes, whereas the
catch
expression cannot. They are described in
Expressions
.
| Class |
Origin |
| error |
Run-time error,
for example, 1+a, or the process called
erlang:error/1,2 |
| exit |
The process called exit/1 |
| throw |
The process called throw/1 |
Exception Classes.
An exception consists of its class, an exit reason
(see Exit Reason),
and a stack trace (which aids in finding the code location of
the exception).
The stack trace can be retrieved using
erlang:get_stacktrace/0
from within a try expression, and is returned for
exceptions of class error from a catch expression.
An exception of class error is also known as a run-time
error.
Exit Reasons
When a run-time error occurs,
that is an exception of class error.
The exit reason is a tuple {Reason,Stack}, where
Reason is a term indicating the type of error:
| Reason |
Type of Error |
| badarg |
Bad argument. The argument is of wrong data type, or is otherwise badly formed. |
| badarith |
Bad argument in an arithmetic expression. |
| {badmatch,V} |
Evaluation of a match expression failed. The value V did not match. |
| function_clause |
No matching function clause is found when evaluating a function call. |
| {case_clause,V} |
No matching branch is found when evaluating a case expression. The value V did not match. |
| if_clause |
No true branch is found when evaluating an if expression. |
| {try_clause,V} |
No matching branch is found when evaluating the of-section of a try expression. The value V did not match. |
| undef |
The function cannot be found when evaluating a function call. |
| {badfun,F} |
Something is wrong with a fun F. |
| {badarity,F} |
A fun is applied to the wrong number of arguments. F describes the fun and the 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,V} |
Trying to evaluate a throw outside a catch. V is the thrown term. |
| 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. The most recent function call tuple can in some
cases be {Module,Name,[Arg]}.