[erlang-questions] net_kernel:handle_call

[Musumeci, Antonio S]

Seems like a rather dangerous paradigm even if the general pattern for dealing with errors is to exit and restart.

While not directly comparable... in other languages when you ask for an invalid service (method, function, etc) the caller not the called errors.

I understand the point about cast but handle_info works the same way too. Additionally to what I said above it seems inconsistent.

________________________________
From: Robert Raschke [mailto:rtrlists@REDACTED]
Sent: Friday, February 19, 2010 11:08 AM
To: Musumeci, Antonio S (IT)
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] net_kernel:handle_call

Hello Antonio,

On Fri, Feb 19, 2010 at 2:49 PM, Musumeci, Antonio S <Antonio.Musumeci@REDACTED<mailto:Antonio.Musumeci@REDACTED>> wrote:
Is it intentional that there is no catch all function declaration in net_kernel for handle_call?

gen_server:call(net_kernel, blah).

or

gen_server:call({net_kernel,remoteNode}, blah).

will cause it to exit.

It's handled fine in the case of casts however.


It is very common for gen_server code to have a

handle_cast(_, State) ->
    {noreply,State}.

if no cast requests are actually implemented, because having no handle_cast/2 at all leads to a compiler warning for the missing callback. You'll see the same done for other "unimplemented" gen_server callback functions like code_change/3 or handle_info/2.

And as you are not meant to use gen_server:call/3 directly, but through a proper interface function you provide as part of your server implementation, most handle_call/3 implementation only have clauses for actually implemented requests.

Robby


--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.