There is a system process with the registered name
error_logger
. This process receives all error messages
from the Erlang runtime system and, by default, writes them to
the terminal (tty):
=ERROR REPORT==== 9-Dec-2003::13:25:02 === Error in process <0.27.0> with exit value: {{badmatch,[1,2,3]},[{m,f,1},{shell,eval_loop,2}]}
The exit values used by the runtime system are described in Erlang Reference Manual, in the chapter about Errors and Error Handling.
The process error_logger
and its user interface (with
the same name) are described in error_logger(3)
. Among
other things, it is possible to define that error information
should be written to a specified file instead of the tty.
The error logger is part of the Kernel application and it is
also possible to use the Kernel configuration parameter
error_logger
to define if error information should be
written to terminal, file or not be written at all. See
kernel(6)
.
During system start-up, errors are written unformatted to
standard out
and also kept in a buffer. All buffered
errors are written again when the intended handler (tty or file)
is installed.
When the error_logger
process is notified about an
error, the message is passed to the the error_logger
on
the node which is the group leader process for the process which
caused the error.
The user can use the standard error_logger
process to
report errors in the application code by calling
the error_logger
module interface functions
error_msg/1
, error_msg/2
, info_msg/1
,
info_msg/2
, format/2
, error_report/1
, and
info_report/1
. See error_logger(3)
.
For example, some of the OTP applications call these functions to report serious errors.
The standard configuration of the error logger supports
the logging of errors to the tty, or to a specified file. There is
also a multi-file logger which logs all events, not only
the standard error events, to several files.
See log_mf_h(3)
.
The error_logger
process is an event manager,
implemented using the standard behaviour gen_event
.
See OTP Design Principles and gen_event(3)
.
It is thus possible to add customized error report event handlers. This may be desirable in order to satisfy one of the following purposes:
The following two functions are used to add and delete handlers:
add_report_handler
to add a handler, and
delete_report_handler
to delete a handler.
New types of error message can be reported with
the error_logger:error_report/2
and
error_logger:info_report/2
functions. Errors which are
reported this way are ignored by the standard error logger event
handlers.
The following event is generated by a process Pid
calling
error_logger:error_report(Type, Report)
:
{error_report, Gleader, {Type, Pid, Report}}
Gleader
is the group leader for the process where the call
originated, i.e. normally Pid
unless, for example,
the function was evaluated using rpc:call/4
).
The following event is generated by a process Pid
calling
error_logger:info_report(Type, Report)
:
{info_report, Gleader, {Type, Pid, Report}}
Example:
-module(my_error_logger_h). -behaviour(gen_event). -export([start/0, stop/0]). -export([report/1]). -export([init/1, handle_event/2, terminate/2]). start() -> error_logger:add_report_handler(my_error_logger_h). stop() -> error_logger:delete_report_handler(my_error_logger_h). report(MyError) -> error_logger:error_report(my_error, MyError). init(_Arg) -> {ok, []}. handle_event({error_report, GL, {Pid, my_error, MyError}}, State) -> io:format("==MY ERROR=======~n", []), io:format("~p ~p ~p~n~n", [GL, Pid, MyError]), {ok, State}; handle_event(_Event, State) -> {ok, State}. terminate(_Arg, _State) -> ok.
The application SASL provides additional error information in the form of crash reports, which are especially useful in a system structured according to the OTP Design Principles. See SASL User's Guide for more information.