[erlang-questions] Improve $handle_undefined_function

[Loïc Hoguin]

Hello,

Just recently the $handle_undefined_function feature was introduced. It 
is a way to override error_handler mechanisms when a function isn't 
found, and works per module for all processes, instead of just one.

Regardless of the intent behind this feature, the implementation that 
was pushed to master is in my opinion, and apparently others, deeply 
flawed. The main issue is that it pushes the responsability of 
propagating the right errors directly to the user, and the user must use 
extra care when writing this handler.

For example this handler would be incorrect:

$handle_undefined_function(monitor, [process, Pid]) ->
     do_something();
$handle_undefined_function(demonitor, Pid) ->
     do_something_else();
$handle_undefined_function(F, Args) ->
     error_handler:raise_undef_exception(?MODULE, F, Args).

Can you see why?[1] If it's not obvious to you, then perhaps this 
feature needs more work.

My proposal is to use an attribute to list the functions defined like 
this, so that error_handler can make the distinction between undef and 
badarg directly. The above function would then be written like this:

$handle_undefined_function(monitor, [process, Pid]) ->
     do_something();
$handle_undefined_function(demonitor, Pid) ->
     do_something_else().

And the issue would be gone.

Adding an attribute isn't hard, whether you generate code or not, and it 
can be used by tools to figure out what's going on with the module, 
providing better integration.

And why not just use -export and still allow -spec anyway? The function 
is exported, has specs, but is just defined elsewhere. I'm sure there 
can be a simple solution that fits a lot better the existing toolbase.

[1] The answer is: if the first argument to 'monitor' is anything other 
than the atom 'process', then an undef error will be triggered instead 
of 'badarg'.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu