aboutsummaryrefslogtreecommitdiffstats
path: root/lib/kernel/doc/src/error_handler.xml
blob: acbf9a2c6ec6bc94521d341c8de03cad12cc09c0 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">

<erlref>
  <header>
    <copyright>
      <year>1996</year>
      <year>2011</year>
      <holder>Ericsson AB, All Rights Reserved</holder>
    </copyright>
    <legalnotice>
  The contents of this file are subject to the Erlang Public License,
  Version 1.1, (the "License"); you may not use this file except in
  compliance with the License. You should have received a copy of the
  Erlang Public License along with this software. If not, it can be
  retrieved online at http://www.erlang.org/.

  Software distributed under the License is distributed on an "AS IS"
  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
  the License for the specific language governing rights and limitations
  under the License.

  The Initial Developer of the Original Code is Ericsson AB.
    </legalnotice>

    <title>error_handler</title>
    <prepared></prepared>
    <docno></docno>
    <date></date>
    <rev></rev>
  </header>
  <module>error_handler</module>
  <modulesummary>Default System Error Handler</modulesummary>
  <description>
    <p>The error handler module defines what happens when certain types
      of errors occur.</p>
  </description>
  <funcs>
    <func>
      <name name="undefined_function" arity="3"/>
      <fsummary>Called when an undefined function is encountered</fsummary>
      <type_desc variable="Args">
        A (possibly empty) list of arguments <c>Arg1,..,ArgN</c>
      </type_desc>
      <desc>
        <p>This function is evaluated if a call is made to
          <c><anno>Module</anno>:<anno>Function</anno>(Arg1,.., ArgN)</c> and
          <c><anno>Module</anno>:<anno>Function</anno>/N</c> is undefined. Note that
          <c>undefined_function/3</c> is evaluated inside the process
          making the original call.</p>
        <p>If <c><anno>Module</anno></c> is interpreted, the interpreter is invoked
          and the return value of the interpreted
          <c><anno>Function</anno>(Arg1,.., ArgN)</c> call is returned.</p>
        <p>Otherwise, it returns, if possible, the value of
          <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> after an attempt has been
          made to autoload <c><anno>Module</anno></c>. If this is not possible, the
          call to <c><anno>Module</anno>:<anno>Function</anno>(Arg1,.., ArgN)</c> fails with
          exit reason <c>undef</c>.</p>
      </desc>
    </func>
    <func>
      <name name="undefined_lambda" arity="3"/>
      <fsummary>Called when an undefined lambda (fun) is encountered</fsummary>
      <type_desc variable="Args">
        A (possibly empty) list of arguments <c>Arg1,..,ArgN</c>
      </type_desc>
      <desc>
        <p>This function is evaluated if a call is made to
          <c><anno>Fun</anno>(Arg1,.., ArgN)</c> when the module defining the fun is
          not loaded. The function is evaluated inside the process
          making the original call.</p>
        <p>If <c><anno>Module</anno></c> is interpreted, the interpreter is invoked
          and the return value of the interpreted
          <c><anno>Fun</anno>(Arg1,.., ArgN)</c> call is returned.</p>
        <p>Otherwise, it returns, if possible, the value of
          <c>apply(<anno>Fun</anno>, <anno>Args</anno>)</c> after an attempt has been made to
          autoload <c><anno>Module</anno></c>. If this is not possible, the call
          fails with exit reason <c>undef</c>.</p>
      </desc>
    </func>
  </funcs>

  <section>
    <title>Notes</title>
    <p>The code in <c>error_handler</c> is complex and should not be
      changed without fully understanding the interaction between
      the error handler, the <c>init</c> process of the code server,
      and the I/O mechanism of the code.</p>
    <p>Changes in the code which may seem small can cause a deadlock
      as unforeseen consequences may occur. The use of <c>input</c> is
      dangerous in this type of code.</p>
  </section>
</erlref>