[erlang-bugs] rpc:call hide throw

[Eric Merritt]

On Mon, May 14, 2012 at 10:23 AM, Samuel <samuelrivas@REDACTED> wrote:
>
> The problem with that is that once you propagate the exception to the
> caller you loose the stack trace.

I am not saying its a good idea mind you, but could you not catch the
exception where its propagated and reraise it in the client with
erlang:raise/3. Again, let me reiterate that I am *not* proposing this
as a solution, I would really need to think out the repercussions
before doing that.

> 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 think we are agreeing here.

> 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.

I thought that catch was actually deprecated. After going and looking
I realize that it is not. Not only that, but the docs don't seem to
mention that its a bad idea.

> 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."

This also sounds like a problem that needs to be fixed, perhaps actual
deprecation and removal of catch?

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

That sounds reasonable to me.

> Regards
> --
> Samuel