## 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:

- to perform additional processing of standard error messages,
- to override the standard behaviour (the standard event handlers must be deleted), or
- to handle new types of error messages.

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.

### 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-2005 Ericsson AB