[erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479)

[Ulf Wiger]

On 22 Jan 2013, at 20:31, Pedram Nimreezi wrote:

> Beyond all conceivable objections the most apparent reality is that
> calling a userland module function that does not exist is an error,
> and trying to "recover" that error is programming defensively.
> This very concept alone violates in some way at least half a dozen
> long standing Erlang programming rules and semantics [1]..

Again (after which I will stop repeating myself), this is exactly 
what error_handler:undefined_function/3 has always done, and
it's a cornerstone of Erlang's on-demand code loading. It was
introduced by the very people who wrote the Erlang 
programming rules and semantics. ;-)

The possibility to make this functionality local to a particular
module simply allows for the possibility that (a) given that 
the existense of error_handler:undefined_function/3 is justified
in the first place, (b) there are other potential implementations
of that function that could serve a useful purpose.

There have been attempts at modifying the error_handler 
hook before, several times in fact. The single most important
argument against doing so is that it serves *all* code running
in the VM, which means that the potential for inadvertently 
breaking someone else's code is extremely high.

The argument that "you'd better know what you're doing" is
a weak one, since there are plenty of areas where this applies.
Off the top of my head, I'd say this is sage advice for anyone
trying their hand at NIFs, Core Erlang, hand-written BEAM ASM
code, patching mnesia internals, etc. Yet all these things are
allowed.

Having said this, I'm not necessarily advocating that this 
feature needs to be included. I feel fairly neutral on the subject,
since:

- It is obscurely named, and obviously doesn't *beg* to be used
- The documentation will surely include stern warnings to the 
  effect that you should really, really avoid messing with it
  unless you have a very good reason to.
- It doesn't really introduce a new feature, as much as it re-
  packages an old one and makes it safer to experiment with.

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com