error_handler(3erl)
π NAME π
okay bestie, meet error_handler β the literal default system error handler, and this is its 3erl manual-page moment. π
Itβs the module that defines what goes down when certain types of errors happen. No cap. β¨
πΈ DESCRIPTION πΈ
This module is the blueprint for what happens when certain types of errors pop off. Thatβs the whole vibe. π«Ά
β¨ EXPORTS β¨
π raise_undef_exception(Module, Function, Args) -> no_return()
Types:
Module = Function = atom()
Args = list()
A (possibly empty) list of arguments Arg1,..,ArgN
This one raises an undef exception with a stacktrace, and the whole point is to say: βbestie, Module:Function/N is undefined.β Periodt. π
π¦ undefined_function(Module, Function, Args) -> any()
Types:
Module = Function = atom()
Args = list()
A (possibly empty) list of arguments Arg1,..,ArgN
So the runtime system calls this function when someone makes a call to Module:Function(Arg1,.., ArgN) and Module:Function/N is undefined. Little detail: this function is evaluated inside the process making the original call. iykyk. π
Hereβs the flow, step by step:
- It first attempts to autoload
Module. - If that is not possible, an
undefexception is raised. π - If it is possible to load
Moduleand functionFunction/Nis exported, it is called. - Otherwise, if function
'$handle_undefined_function'/2is exported, it is called as'$handle_undefined_function'(Function, Args).
β οΈ Warning: Defining'$handle_undefined_function'/2in 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'/2and 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 is raised. Thatβs the tea. π
π undefined_lambda(Module, Fun, Args) -> term()
Types:
Module = atom()
Fun = function()
Args = list()
A (possibly empty) list of arguments Arg1,..,ArgN
This function gets evaluated if a call is made to Fun(Arg1,.., ArgN) when the module defining the fun is not loaded. And yes, it is evaluated inside the process making the original call. π
The glow-up logic:
- If
Moduleis interpreted, the interpreter is invoked and the return value of the interpretedFun(Arg1,.., ArgN)call is returned. - Otherwise, it returns, if possible, the value of
apply(Fun, Args)after an attempt is made to autoloadModule. - If this is not possible, the call fails with exit reason
undef. π
π₯ NOTES π₯
okay so this part is serious, bestie: the code in error_handler is complex. Do not change it without fully understanding the interaction between the error handler, the init process of the code server, and the I/O mechanism of the code. π§
Code changes that seem small can cause a deadlock, as unforeseen consequences can occur. And the use of input is dangerous in this type of code. This is not the place for main character energy. ππ
Sign-off time: shoutout to Ericsson AB, kernel 8.5.4.2, and error_handler(3erl) β and the footer has no date, so Iβm not inventing one, bestie ππβ¨
π¦ where this page comes from
- ubuntu noble: erlang-manpages 1:25.3.2.8+dfsg-1ubuntu4 Β· Apache-2.0
- ubuntu noble: erlang-manpages 1:25.3.2.8+dfsg-1ubuntu4.8 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms