[erlang-questions] Improve $handle_undefined_function

[Evan Miller]

On Mon, Jan 21, 2013 at 12:04 PM, Loïc Hoguin <essen@REDACTED> wrote:

> 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.
>

This is a great point. An attribute is one solution. Another would be
adding another function, e.g.
$should_handle_undefined_function(FunctionName, Arity), that determines at
run-time whether to call the handler.

$should_handle_undefined_function(monitor, 2) -> true;
$should_handle_undefined_function(demonitor, 1) -> true;
$should_handle_undefined_function(_, _) -> false.

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

What do you think?

Evan



>
> 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
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130121/ced4c317/attachment.htm>