error_handler
Default System Error Handler
The error handler module defines what happens when certain types of errors occur.
Functions
undefined_function(Module, Function, Args) -> any()
Module = Function = atom()
Args = list()
Arg1,..,ArgN
This function is called by the run-time system if a call is made to
and
is undefined. Note that
undefined_function/3
is evaluated inside the process
making the original call.
This function will first attempt to autoload
. If that is not possible,
an undef
exception will be raised.
If it was possible to load
and the function
is exported,
it will be called.
Otherwise, if the function '$handle_undefined_function'/2
is exported, it will be called as
'$handle_undefined_function'(
Warning!
Defining '$handle_undefined_function'/2
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
analysis (such as Dialyzer and Xref) supports the use of
'$handle_undefined_function'/2
and no such support
will be added. Only use this function after having carefully
considered other, less dangerous, solutions. One example of
potential legitimate use is creating stubs for other
sub-systems during testing and debugging.
Otherwise an undef
exception will be raised.
raise_undef_exception(Module, Function, Args) -> no_return()
Module = Function = atom()
Args = list()
Arg1,..,ArgN
Raise an undef
exception with a stacktrace indicating
that
is
undefined.
undefined_lambda(Module, Fun, Args) -> term()
Module = atom()
Fun = function()
Args = list()
Arg1,..,ArgN
This function is evaluated if a call is made to
when the module defining the fun is
not loaded. The function is evaluated inside the process
making the original call.
If
is interpreted, the interpreter is invoked
and the return value of the interpreted
call is returned.
Otherwise, it returns, if possible, the value of
apply(
after an attempt has been made to
autoload
. If this is not possible, the call
fails with exit reason undef
.
Notes
The code in error_handler
is complex and should not be
changed without fully understanding the interaction between
the error handler, the init
process of the code server,
and the I/O mechanism of the code.
Changes in the code which may seem small can cause a deadlock
as unforeseen consequences may occur. The use of input
is
dangerous in this type of code.