Why can't I catch Process.exit/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

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 — OTP 29.0.2 (erts 17.0.2)

while exit/2 sends an exit signal:

Sends an exit signal with exit reason Reason to the process or port identified by Pid.
erlang — OTP 29.0.2 (erts 17.0.2)

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:

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.

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

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.

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

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.

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

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

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.