catch link(Pid) when trapping exits

[Robert Virding]

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