[Ericsson AB]

2 Error Logging

2.1 Error Information From the Runtime System

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.

2.2 User Defined Error Information

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.

2.3 Logging To Disk

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).

2.4 Adding A Customized Event Handler To Error Logger

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:

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.
    

2.5 SASL Error Logging

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.


Copyright © 1991-2004 Ericsson AB