catch link(Pid) when trapping exits

[Raimo Niskanen]

robert.virding@REDACTED (Robert Virding) writes:

I have dug into the archives...

This was introduced fairly recently, in R9B, in conjunction
with the rewrite for more than 255 remote nodes.

We will look into this and decide what to do.

> No, no, no it should definitely NOT return error(noproc).
> 
> The reason is that the whole process communication mechanism,
> including links, was originally designed to be asynchronous on the
> sending side. Sending a message is asychronous, ou don't wait in the
> send to find out if it arrived. Link/1 works the same way. The call
> does not wait until the link is set up but just sends the request and
> continues. If the process does not exist the caller is notified by a
> noproc exit signal from the non-existent process (yes I know but from
> who else could it receive it?).
> 
> The important point is that in bothe cases the call is
> asynchronous. This also means, mostly importantly, that both calls
> function the same way irrespective of whether the other process is
> local or remote. This was also an original goal.
> 
> If this has significantly changed since then then someone has missed
> the original intentions.
> 
> Robert
> 
> 
> Francesco Cesarini (Erlang Training & Consulting) wrote:
> 
> >> It is all there, really. Only it was written before exceptions
> >> were invented as a concept in Erlang, uses the term
> >> "exit signal" in a confusing way and lies about "does not fail".
> >> Ok, it is maybe dead wrong, but the intention was right.
> >> So, what happens is:
> >>
> >> link(Pid) -> true           if Pid exists or the caller has
> >>                             process_flag(trap_exit, true).
> >>              error(noproc)  otherwise
> >>
> >> The enclosing catch evaluates to {'EXIT',{noproc,Stackdump}}
> >> for error(noproc).            Weird behaviour, in my opinion..
> >
> >
> > Exactly my point. Would it not be better to return error(noproc)
> > even if trapping exits instead of exit(Pid, Reason)?
> >
> > Francesco
> > -- 
> > http://www.erlang-consulting.com
> >
> >

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB