[erlang-questions] rpc:call/4

[bile@REDACTED]

May be an oversight or a relic. It's due to rpc:handle_call_call doing
a catch apply. Since catch throw gives back whatever was thrown and not
{'EXIT',_} all it can do is pass it back as a normal result.

While it'd be nice in this case to use the newer try catch behavior it'd
not be backward compatible. Though it'd probably lead some to find that
their RPCs had been failing.

And if it were changed... what would the first element of the tuple be?
'EXIT' like exit and error or something like 'THROW'. It'd be nice if
it were 'EXIT', 'ERROR', and 'THROW'. That's even more incompatible
however.

On Thu, 18 Feb 2010 00:38:34 -0800
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)?
>