[erlang-questions] error_handler and local Fun limitations
Mikael Pettersson
mikpelinux@REDACTED
Tue Jun 20 11:34:23 CEST 2017
By defining '$handle_undefined_function'/2 in a module, that module can
catch and handle wrong-arity calls to the module's top-level functions.
(The standard error_handler is also involved.)
Unfortunately, this behaviour is limited to top-level functions, either
M:F(...) calls, or Fun(...) calls where Fun = fun M:F/N.
For local Funs, the first issue is that beam_emu.c:call_fun() states:
* There is a module loaded, but obviously the fun is not
* defined in it. We must not call the error_handler
* (or we will get into an infinite loop).
and then skips calling the error_handler.
What is this infinite loop, and could we do something to prevent it?
The second issue is that even if beam_emu routes a wrong-arity Fun(...)
call via the error_handler to a handler in the Fun's module, that handler
has no sane way to identify the Fun. In the erlang:fun_info/[12] output,
the index/uniq values are of no use (that I can see), and the name is
"generated by the compiler, and is only of informational use".
What I'd really want is a way to attach my own attribute to a fun
expression, and have erlang:fun_info/[12] return it.
Being able to handle wrong-arity calls to local Funs would simplify
compiling languages like Scheme to the BEAM. Scheme has both fixed-arity
and variable-arity functions, and since it's dynamically typed you don't
know at a call site what kind of function you're calling.
/Mikael
More information about the erlang-questions
mailing list