Why can't I catch Process.exit/2?

Questions / Help
1

Alright, fair warning: I may be missing something obvious here.

I can use try/catch to catch an exit sent with exit/1:

try
  exit(:timeout)
catch
  :exit, :timeout -> :ok
end

But if I catch an exit sent with Process.exit/2, it doesn’t work (it exits):

try
  Process.exit(self(), :timeout)
  :timer.sleep(1000)
catch
  :exit, :timeout -> :ok
end

What’s really getting me here is I can’t find any mention of this in the docs. I managed to find one random comment which mentions this fact completely off-hand, and that’s it.

Am I missing something?

2

I think you want to look at Process.flag/2 and the meaning of :trap_exit. It still won’t do what you want, as you’ll need to handle it by receiving the message in the process mailbox

1 Like
3

elixir function Kernel.exit/1 delegates to erlang exit/1 while Process.exit/2 delegates to erlang exit/2.

if you read the erlang documentation:
exit/1 raises an exception:

Raises an exception of class exit with exit reason Reason.
erlang — erts v15.2.1

while exit/2 sends an exit signal:

Sends an exit signal with exit reason Reason to the process or port identified by Pid.
erlang — erts v15.2.1

that’s why a catch can handle an exit/1 call but not an exit/2.

You can get more details on erlang doc for processes:
https://www.erlang.org/doc/system/ref_man_processes.html

4 Likes
4

I suppose this is the documentation you were looking for:

The functions erlang:exit/1 and erlang:exit/2 are named similarly but provide very different functionalities. The erlang:exit/1 function should be used when the intent is to stop the current process while erlang:exit/2 should be used when the intent is to send an exit signal to another process. Note also that erlang:exit/1 raises an exception that can be caught while erlang:exit/2 does not cause any exception to be raised.

2 Likes
5

Thank you both, I found those erlang docs but I missed that one line :slight_smile:

6

Think of it this way. If you do not have the sleep(1000), do you still expect to catch the exit here? No, right? It is because the Process.exit() is just sending a signal; the function call itself is fine. Now, it may be reasonable to expect that if the sleep is interrupted by the exit signal, the sleep would re-raise it as an exception; however, Elixir’s sleep does not do that.

7

This is indeed how you would do it, but the use case I was stumbling upon was actually, strangely, the opposite:

I was trying to replicate (fake) GenServer timeouts by sending Process.exit from another process. But that’s not actually how GenServer calls time out, they call exit/1 (in erlang) from within the caller process in a receive/after block, so I couldn’t get it right.

Obviously what I was doing was extremely cursed and unusual, but I was really just wondering what the difference was since I didn’t spot it in the docs :slight_smile:

8

To be clear, the sleep is interrupted by the exit signal. The second example exits immediately (not after one second). It’s just impossible to catch the exit for reasons mentioned above.

9

Exactly. My point is, to do what you want it to do, the sleep would need to be enhanced to install a clean up callback and raise when something else happened. It is a lot of work for no apparent gain. The Elixir document on sleep is clear that you should not use it: Process — Elixir v1.18.2

Use this function with extreme care. For almost all situations where you would use sleep/1 in Elixir, there is likely a more correct, faster and precise way of achieving the same with message passing
1 Like
10

I’m not sure I follow what you mean. The reason I put a sleep there is because I was afraid that the Process.exit/2 signal was asynchronous and would arrive after the catch block closed, and I was trying to figure out how to catch it.

But it doesn’t matter because you can’t catch the signal anyway (I did not understand this).

11

You are correct. Ask yourself this question: Why try … catch should catch asynchronous event? Do you expect this to catch also?

Process.exit(self(), :timeout)
try
  :timer.sleep(1000)
catch
  :exit, :timeout -> :ok
end

You can; you just need to do Process.flag(:trap_exit, true) and have a handle_info clause to handle the {:EXIT, pid, reason} message that you would receive.

2 Likes
12

Well obviously not anymore! :slight_smile: But if it worked the way I thought it did when I opened the thread, I would have expected the possibility of a race condition (the signal arriving before the try/catch is opened). So, if it worked that way (it does not!), then it would be random.

As I said, I meant catch literally (a catch block). I was not talking about trapping exits.

13

And just to be clear, there are some things which work this way. For example, what happens here?

Process.send_after(self(), :foo, 1)
receive do
  :foo -> :ok
after
  1 -> :error
end

It’s a race!