catch link(Pid) when trapping exits

[Raimo Niskanen]

Sorry, I read the source wrong. Should have tried instead. 
It is an old behaviour.

rickard.s.green@REDACTED (Rickard Green) writes:

> No, this behavior was there before R9B, e.g. R5B01:
> 
> /usr/local/otp/releases/otp_beam_sunos5_r5b01_patched/bin/erl
> Erlang (BEAM) emulator version 4.8.2.8
> 
> Eshell V4.8.2.8  (abort with ^G)
> 1> catch link(pid(0,1234,0)).
> {'EXIT',{noproc,{shell,evaluator,[link,[<0.1234.0>]]}}}
> 2> process_flag(trap_exit,true).
> false
> 3> catch link(pid(0,1234,0)).
> true
> 4> flush().
> Shell got {'EXIT',<0.1234.0>,noproc}
> ok
> 5>
> 
> It was introduced before OTP. I had a quick look at the R1 code and it
> was present there too.
> 
> Regards,
> Rickard Green, Erlang/OTP
> 
> Raimo Niskanen wrote:
> > 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