catch link(Pid) when trapping exits

Rickard Green
Sat Oct 29 00:37:43 CEST 2005

No, this behavior was there before R9B, e.g. R5B01:

Erlang (BEAM) emulator version

Eshell V4.8.2.8  (abort with ^G)
1> catch link(pid(0,1234,0)).
2> process_flag(trap_exit,true).
3> catch link(pid(0,1234,0)).
4> flush().
Shell got {'EXIT',<0.1234.0>,noproc}

It was introduced before OTP. I had a quick look at the R1 code and it 
was present there too.

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

More information about the erlang-questions mailing list