<div dir="ltr"><div class="gmail_extra">On Mon, Jan 21, 2013 at 12:04 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello,<br>
<br>
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.<br>
<br>
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.<br>

<br>
For example this handler would be incorrect:<br>
<br>
$handle_undefined_function(<u></u>monitor, [process, Pid]) -><br>
    do_something();<br>
$handle_undefined_function(<u></u>demonitor, Pid) -><br>
    do_something_else();<br>
$handle_undefined_function(F, Args) -><br>
    error_handler:raise_undef_<u></u>exception(?MODULE, F, Args).<br>
<br>
Can you see why?[1] If it's not obvious to you, then perhaps this feature needs more work.<br>
<br>
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:<br>
<br>
$handle_undefined_function(<u></u>monitor, [process, Pid]) -><br>
    do_something();<br>
$handle_undefined_function(<u></u>demonitor, Pid) -><br>
    do_something_else().<br>
<br>
And the issue would be gone.<br></blockquote><div><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">$should_handle_undefined_function(monitor, 2) -> true;</div><div style="font-family:arial,sans-serif;font-size:13px">
$should_handle_undefined_function(demonitor, 1) -> true;</div><div style="font-family:arial,sans-serif;font-size:13px">$should_handle_undefined_function(_, _) -> false.</div><div class="im" style="font-family:arial,sans-serif;font-size:13px">
<div><br></div><div>$handle_undefined_function(monitor, [process, Pid]) -> do_something();</div><div>$handle_undefined_function(<u></u>demonitor, Pid) -> do_something_else().<br></div><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">
What do you think?</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">Evan</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

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

<br>
[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'.<span class=""><font color="#888888"><br>

<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</font></span></blockquote></div><br><br></div></div>