[erlang-questions] rpc:call/4

[Jayson Vantuyl]

Is this true?

I mean, exit / error / throw has always been a very weird division to me.  I can't say that I completely understand what the breakdown is, although I usually know which one I should use.  Generally, throw is used as a form of high-level flow control, exit is for when you explicitly intend to exit a process, and error is for when you have an error (which defaults to terminating the process, but can be caught if it's expected).

I can't imagine that the case catch is the right way to do it.  The behavior is undocumented, and I really can't imagine that we should rely on it.

As much as I love stability, I think it's safe to say that it's reasonable to expect people to update their code to run on updated versions of Erlang.  This is why we deprecate things and have release notes.  I can't imagine this to be any more disruptive than, say, deprecating the re module.

As a member of the Erlang community, I really don't think we should go this direction:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4273532

That said, I'd love to hear from someone at Ericsson whether they think this is a bug.

From the documentation, I think so.  Intuitively I also feel that it's bad because it means that you can't distinguish between a throw and a return value if you use rpc:call.  This is really a bad design bug in any rpc mechanism that wants to be event remotely transparent.  I understand that when rpc was written, this was the only tool available.  Times have changed.

Is it worth my time to submit a patch?  For that matter, I'd be interested in just eliminating this idiom from the whole of OTP.  I don't think it's ever justified anymore.  Of course, a crude check shows 2082 occurrences.  That would be a pretty big patch.  Then again, 370 of them are in tests, so that might be a good place to start...

On Feb 19, 2010, at 1:26 AM, Vinayak Pawar wrote:

> erlang:throw is mainly intended for doing non-local returns from function
> instead of error handling. Hence that bit odd rpc:call behaviour?
> 
> Regards,
> Vinayak
> 
> On Thu, Feb 18, 2010 at 2:08 PM, Jayson Vantuyl <kagato@REDACTED> wrote:
> 
>> I've encountered unexpected behavior when doing rpc:call/4 to a remote node
>> and the remote code has an exception.
>> 
>> The "error case" seems to be {badrpc,Reason}, with reason completely
>> unspecified.  Oddly, I get the following behavior:
>> 
>> erlang:exit(X) gives {badrpc, {'EXIT',X}.
>> erlang:raise(X) gives {badrpc, {'EXIT',X,StackTrace}.
>> erlang:throw(X) gives X.
>> 
>> The first two are pretty reasonable.  The third one is a bit odd.
>> 
>> In a number of places, the rpc:call infrastructure seems to use the
>> archaic:
>> 
>>> case catch .... of ... end.
>> 
>> In modern code, I would assume this would be the more expressive:
>> 
>>> try ... of ... catch ... end.
>> 
>> What is the expected behavior (the docs are a bit vague)?
>> 
>> --
>> Jayson Vantuyl
>> kagato@REDACTED
>> 
>> 
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>> 
>> 

-- 
Jayson Vantuyl
kagato@REDACTED