small medium large xlarge

15 Jul 2013, 03:42
Dave Thomas (396 posts)
  • Do the same, but have the child raise an exception. What difference do you see in the tracing.
06 Jan 2015, 20:24
Pierre Sugar (57 posts)
defmodule Crash2 do

  def one_time(sender) do
    send sender, "Just a message from Crash2"
    raise RuntimeError, message: "Did it by purpose"

  def check_for_message do
    receive do
       msg ->
        IO.puts "Received another message #{inspect msg}"
    after 500 ->
      IO.puts "no more messages"

  def run do
    Process.flag(:trap_exit, true)
    res = spawn_link(Crash2, :one_time, [self])

    IO.puts inspect res



The difference to raising an exception instead of calling exit is that the exception is printed directly from the child process (at least seems like it). But it is also captured by the parent process together with the message from the child.

Result when running


21:16:46.654 [error] Error in process <0.749.0> with exit value: {#{'__exception
__'=>true,'__struct__'=>'Elixir.RuntimeError',message=><<17 bytes>>},[{'Elixir.C
Received another message "Just a message from Crash2"
received another message {:EXIT, #PID<0.749.0>, {%RuntimeError{message: "Did it
by purpose"}, [{Crash2, :one_time, 1, [file: 'crash2.exs', line: 5]}]}}
no more messages

Intersting finding. When I don’t wait for the messages, that is comment out the check_for_message and call Crash2.exs after that with check_for_message the messages from the previous call are also captured. It seems the messages keep hanging around until someone is reading them.

04 Jun 2015, 11:13
Stefan Chrobot (14 posts)

Pierre, this is because in both runs, self refers to the same process, which can be easily observed by putting


inside the run function.

23 Oct 2015, 22:13
theofanis melios (1 post)

I just wanted to mention that exercises-3 and 4 should not trap the exit as in Pierre Sugar solution. It defeats the purpose on what the author is trying to convey.

3 should show that performs an exit 4 should show that an exception is raised

exercise 5 should show that the exit was actually trapped by spawning the process with spawn_monitor. The author mentioned that spawn_link should be used when you do not need to trap the program meaning let it fail, while spawn_monitor allows you to continue on.

The next exercise should show that the message was receive.

I just wanted to post this so readers do not get confused as I did when viewing solutions.

01 Feb 2018, 18:04
António Alvarenga (1 post)

the sleep function only alters the order of the returns, right? everything is returned either way

You must be logged in to comment