raising inside dbg is not handled

[dkuku]

Elixir and Erlang/OTP versions

any recent

Operating system

any

Current behavior

Currently when there is an exception we don't get any output in dbg. When debugging pipes I need to add inspects in the pipeline idealy with labels to see where it failed.

[:a, :b]
|> then(fn _ -> raise "breaks dbg" end)
|> dbg

returns

** (RuntimeError) breaks dbg
    #cell:exemuvvgh6ktixl2:2: (file)

Expected behavior

Rendering partial result would be ideal, this way we would know what was the input to the failing function.
Currently the dbg is generated in 2 steps

• code is executed
• then the result string is generated

It may be possible if the dbg result would be generated where the code is executed and in case of exceptions we could just display what was generated up to that point.

      abc() #=> [:a, :b, :c]
     |> tl() #=> [:b, :c]
     |> then(fn _ -> raise "boom" end)
      ** (RuntimeError) boom
    #cell:exemuvvgh6ktixl2:3: (file)

[sabiwara]

It may be possible if the dbg result would be generated where the code is executed and in case of exceptions we could just display what was generated up to that point.

It's an interesting idea, but I think it's a trade-off though: if intermediate steps are printing to stdout too, the pipeline might become unreadable:

iex(1)> :world |> then(&IO.puts("hello #{&1}!")) |> Atom.to_string() |> dbg()
hello world!
[iex:1: (file)]
:world #=> :world
|> then(&IO.puts("hello #{&1}!")) #=> :ok
|> Atom.to_string() #=> "ok"

would become

[iex:1: (file)]
:world #=> :world
hello world!
|> then(&IO.puts("hello #{&1}!")) #=> :ok
|> Atom.to_string() #=> "ok"

We could also imagine wrapping in a try + reraise, but I'm not sure it's a good approach either. Adding more intermediate dbg before the raising step might be the best approach here?

[dkuku]

What motivated me to create this issue was dbg on a simple function call:

function(param1, param2)
|> dbg

The function raised and I had to add inspects before it.

[josevalim]

I would avoid try-catch. But I think the intermediate printing would be nice!

[dkuku]

Something like this example? This will allow calling dbg on the condition.
It would be good to refactor it first to a new Macro.Dbg module

  defp dbg_ast_to_debuggable({:if, meta, [condition_ast, clauses]} = ast, env, options) do
    condition_result_var = unique_var(:condition_result, __MODULE__)
    result_var = unique_var(:result, __MODULE__)

    quote do
      Macro.write_underline("If condition", unquote(options))
      unquote(condition_result_var) = unquote(condition_ast)

      Macro.write_ast_value(
        unquote(escape(condition_ast)),
        unquote(condition_result_var),
        unquote(options)
      )

      Macro.write_underline("If expression", unquote(options))
      unquote(result_var) = unquote({:if, meta, [condition_result_var, clauses]})

      Macro.write_ast_value(
        unquote(escape(ast)),
        unquote(result_var),
        unquote(options)
      )

      unquote(result_var)
    end
  end

[josevalim]

That would work for if 👍 but we need to be careful with other changes where dbg may change the semantics of the code and therefore we end up debugging something differently than is actually being invoked. :)

[josevalim]

@dkuku would you like to send a PR here?

[dkuku]

@josevalim I'm thinking about it, but I believe it requires changes to all current debug implementations.
Do you have any ideas about how to implement this gradually?
Also, if someone wants to pick it up before I do, please feel free to do so.

[josevalim]

Sorry, we may be speaking about two different things then. It thought this would ultimately simply attach more information to if?

[dkuku]

This is not the complete PR. I was experimenting with moving the dbg to a new module and exposing the private functions from macro as public.
My idea was to print the dbg output when data is available without aggregating anything and then formatting it in the next function like it's done right now. This way, if it crashes, we can still see what happened up to this point.

[josevalim]

@dkuku I got it. We can do it one by one, we don't need to change them all at once, especially because I don't think we can necessarily change all of them. :)

[dkuku]

I have the pr for if somewhere, I will send it this week.

[josevalim]

if and case seem to be the most straight-forward ones, we just print the value before hand. I think pipe is doable. cond and with are probably not worth the trouble.