diff options
Diffstat (limited to 'lib/kernel/doc/src/error_handler.xml')
| -rw-r--r-- | lib/kernel/doc/src/error_handler.xml | 78 |
1 files changed, 39 insertions, 39 deletions
diff --git a/lib/kernel/doc/src/error_handler.xml b/lib/kernel/doc/src/error_handler.xml index 6aec5c77d5..14e7537d1f 100644 --- a/lib/kernel/doc/src/error_handler.xml +++ b/lib/kernel/doc/src/error_handler.xml @@ -31,35 +31,48 @@ <rev></rev> </header> <module>error_handler</module> - <modulesummary>Default System Error Handler</modulesummary> + <modulesummary>Default system error handler.</modulesummary> <description> - <p>The error handler module defines what happens when certain types + <p>This module defines what happens when certain types of errors occur.</p> </description> <funcs> <func> + <name name="raise_undef_exception" arity="3"/> + <fsummary>Raise an undef exception.</fsummary> + <type_desc variable="Args"> + A (possibly empty) list of arguments <c>Arg1,..,ArgN</c> + </type_desc> + <desc> + <p>Raises an <c>undef</c> exception with a stacktrace, indicating + that <c><anno>Module</anno>:<anno>Function</anno>/N</c> is + undefined. + </p> + </desc> + </func> + <func> <name name="undefined_function" arity="3"/> - <fsummary>Called when an undefined function is encountered</fsummary> + <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 called by the run-time system if a call is made to + <p>This function is called by the runtime system 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 + <c><anno>Module</anno>:<anno>Function</anno>/N</c> is undefined. + Notice that this function is evaluated inside the process making the original call.</p> - <p>This function will first attempt to autoload + <p>This function first attempts to autoload <c><anno>Module</anno></c>. If that is not possible, - an <c>undef</c> exception will be raised.</p> + an <c>undef</c> exception is raised.</p> - <p>If it was possible to load <c><anno>Module</anno></c> - and the function <c><anno>Function</anno>/N</c> is exported, - it will be called.</p> + <p>If it is possible to load <c><anno>Module</anno></c> + and function <c><anno>Function</anno>/N</c> is exported, + it is called.</p> - <p>Otherwise, if the function <c>'$handle_undefined_function'/2</c> - is exported, it will be called as + <p>Otherwise, if function <c>'$handle_undefined_function'/2</c> + is exported, it is called as <c>'$handle_undefined_function'(</c><anno>Function</anno>, <anno>Args</anno>). </p> @@ -67,61 +80,48 @@ <p>Defining <c>'$handle_undefined_function'/2</c> in ordinary application code is highly discouraged. It is very easy to make subtle errors that can take a long time to - debug. Furthermore, none of the tools for static code + debug. Furthermore, none of the tools for static code analysis (such as Dialyzer and Xref) supports the use of <c>'$handle_undefined_function'/2</c> and no such support will be added. Only use this function after having carefully - considered other, less dangerous, solutions. One example of + considered other, less dangerous, solutions. One example of potential legitimate use is creating stubs for other sub-systems during testing and debugging. </p> </warning> - <p>Otherwise an <c>undef</c> exception will be raised.</p> - </desc> - </func> - <func> - <name name="raise_undef_exception" arity="3"/> - <fsummary>Raise an undef exception</fsummary> - <type_desc variable="Args"> - A (possibly empty) list of arguments <c>Arg1,..,ArgN</c> - </type_desc> - <desc> - <p>Raise an <c>undef</c> exception with a stacktrace indicating - that <c><anno>Module</anno>:<anno>Function</anno>/N</c> is - undefined. - </p> + <p>Otherwise an <c>undef</c> exception is raised.</p> </desc> </func> <func> <name name="undefined_lambda" arity="3"/> - <fsummary>Called when an undefined lambda (fun) is encountered</fsummary> + <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 + <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> + <c>apply(<anno>Fun</anno>, <anno>Args</anno>)</c> after an attempt + is 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 + <p>The code in <c>error_handler</c> is complex. Do not + change it 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 + <p>Code changes that seem small can cause a deadlock, + as unforeseen consequences can occur. The use of <c>input</c> is dangerous in this type of code.</p> </section> </erlref> |