[erlang-bugs] rpc:call hide throw

[Samuel]

> I would equate this to the use of 'catch'. The argument against that
> use that you can't tell valid return values from thrown return values.
> The solution is "don't use catch, use one of the try forms".  That
> same argument would seem to apply here. However, In this case there is
> no form that propagates the exception in any way. Perhaps some
> additional rpc:call_<x> or rpc:<x>_call needs to be added that either
> propagates the exception as an exception (problematic I know) or wraps
> all values in a tuple in the normal erlang way. `{ok, <valid-result>}`
> or `{exit | throw | error, <thrown-value>}`.

The problem with that is that once you propagate the exception to the
caller you loose the stack trace. Also throwing outside a catching
construct is an error in the called side, that should't propagate as
valid return to the calling side.

I've come across many instances of these problem trying to use throws
as exceptions. We (me and Richard Carlsson reported a possible bug to
the list as OTP behaviour callbacks do the same thing, and recently we
saw the same problem in dynamic pages in yaws (though that has already
been fixed by Steve Vinoski).

The underlying issue is that catch and try-catch have really different
behaviour concerning throws. I'd like to think that catch is legacy
and shouldn't be used, as that enables developers to use throw as it
is defined in http://www.erlang.se/workshop/2004/exception.pdf. That
is, an uncaught exception behaves as a no_catch error, with a proper
stack trace. This way, throws can be used both as non-local returns
and as exceptions. However, there seem to be lots of catches in tools
there that hinder what I understand is "the intended use of throw
nowadays."

For this concrete case I think the rpc should fail, as
throw(some_reason) does fail if you call it outside any catch
construct.

Regards
-- 
Samuel