[erlang-bugs] rpc:call hide throw

[Richard Carlsson]

Well, a "nonlocal return" is also an exception. It's just a different 
class of exception than exits and errors. The question here is whether 
the rpc really ought to catch the trow and convert it to a regular 
return value, as done currently, or if it should let the caller know for 
sure that the code terminated with a throw.

The documentation for rpc:call() just says that you should get {badrpc, 
Reason} "if the call fails". And exactly what Reason is in this case is 
not specified further. Turns out, it's whatever you got from "catch 
apply(M,F,As)" if that yields {'EXIT',...}, so if the rpc failed with an 
error, you get a stack trace, but if it failed with an exit, you don't 
get a stack trace. This is all rather messy.

    /Richard

On 2012-05-14 08:33, Robert Virding wrote:
> erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See
>
> http://www.erlang.org/doc/man/erlang.html#throw-1
>
> We don't throw errors in erlang. :-)
>
> Robert
>
> ----- Original Message -----
>> ---------- Forwarded message ----------
>> From: Vyacheslav Vorobyov<vjache@REDACTED>
>> Date: 2012/5/11
>> Subject: rpc:call hide throw
>> To: erlang-bugs@REDACTED
>>
>>
>> Hello,
>>
>> % 1. Good behavior
>> {badrpc,{'EXIT', some_reson }} =
>> rpc:call(node(),erlang,exit,[some_reson]).
>>
>> % 2. Bad behavior
>> some_reson = rpc:call(node(),erlang,throw,[some_reson]).
>>
>> The second case describes an issue. It makes indistinguishable normal
>> result from exception.
>>
>>
>> --
>> Best Regargs,
>>       Vyacheslav
>>
>>
>> --
>> Best Regargs,
>>       Vyacheslav
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs