[erlang-questions] Improve $handle_undefined_function

[Tony Rogvall]

On 21 jan 2013, at 19:04, 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.
> 
This is strange. You think that every one should stay away from this feature, but then you start to play
around with it your self. Why? Are better suited to handle this abomination than the rest of us or what? 

> 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.
> 
What is the fix? ...

> 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:
> 
Wow, you really want to contribute to the development of Erlang.

> $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.
> 
Now we are getting creative and cooperative, I like that.

Here is a smiley for you 

:-)

/Tony

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

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130121/6e642256/attachment.htm>