Fri Jan 18 17:48:33 CET 2013
Parameterized modules were not documented, but that
did not prevent people from using them.
Nowadays we generally prefer to document everything,
but add warnings in the documentation if we think
it could be abused. We might add such warnings to
the documentation of $handle_undefined_function.
Although other languages may give the programmer
more rope to hang himself, Erlang already provides
plenty of rope, for instance parse_transforms, NIFs,
and the error_handler module. Using
$handle_undefined_function is safer than modfying
error_handler, since it can be done locally to a single
module. So we have shortened the rope. :-)
On Fri, Jan 18, 2013 at 4:53 PM, Loïc Hoguin <> wrote:
> On 01/18/2013 04:25 PM, Björn Gustavsson wrote:
>> On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma <
>> <mailto:>**> wrote:
>> On 01/15/2013 10:41 AM, Joe Armstrong wrote:
>>> Golly - I read the code - you modified error_handler.erl !!!!
>>> So what happens is ...
>>> I call android:fooBar(Args) - fooBar is not defined in android.erl
>>> so it's caught in error_handler and then android:rpc(fooBar,
>>> [...]) is called
>>> and this ends up as a Json call to a socket -
>>> Yes, that is what happens.
>>> It might interest you to know, that in R16, you can have a handler for
>> undefined functions in each module. (We needed that to implement the parse
>> transformation for parameterized modules.)
>> This new feature has just been merged to the master branch:
> This sounds like a temporary workaround with potentially very bad uses.
> Why was it documented?
> Loďc Hoguin
> Erlang Cowboy
> Nine Nines
Björn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions