Help an Elixir beginner find missing development tooling!

Cool.

Take a look at this presentation where Luke explains some debugging techniques:

It helped me hope it does the same for you.

Not possible as in most cases the failed process do not exist (unhandled exceptions will kill current process), so there is no “context” you can attach to.

As well I doubt that it would be possible, as Erlang do not provide anything like Kernel#local_variables in Ruby. Also as it was said earlier - process is probably dead when the error handling take place, so there is no “context”. Oh, and by the way, as Elixir compiles to Erlang code, and Erlang allows only one assignment per variable name (SSA-like) the “Elixir variables” will have non-meaningful names in Erlang code.

There was mix console but it was removed. I do not know what was the rationale. But if you do not like it, then you can always create custom command or alias (within Mix) or shell alias.

There is Sobelow, but I do not know if this audit the dependencies. For tool that checks deps for security issues we would need centralised log of such issues, AFAIK there is none, and AFAIK Elixir didn’t had any CVE assigned yet.

How would that even work? Really, I cannot imagine.

There’s Kernel.binding/1: Kernel — Elixir v1.20.2

Unfortunately it is macro, so it will not work in exception handling.

Huh?

iex(1)> a = 42
42
iex(2)> try do 
...(2)>   throw :ack
...(2)> catch v ->
...(2)>   b = 6.28
...(2)>   IO.inspect(binding(), label: :Bindings)
...(2)> end
Bindings: [a: 42, b: 6.28, v: :ack]
[a: 42, b: 6.28, v: :ack]

If a binding ‘can’ be used in the local scope, then binding() will show it, it just compiles to a keyword list of bindings names to the bindings themselves, like [a: a, b: b, v: v]. Is there a case where it will not show a binding that ‘can’ in fact be accessed in the local scope?!

Thanks for this tip! Do you happen to remember what version this was in? I spot checked a couple of versions through 1.3 and didn’t see anything.

Ah! Interesting. Is it possible to retrieve a context for the binding call from System.stacktrace? If so, then we could plug it (ha! no pun intended!) into the Plug.Debugger to retrieve bindings for each level of the stack trace. The issue here is the bindings for Plug.Debugger won’t be helpful, we need bindings up the stack.

That information is already available at compile time via macro’s, so a macro can already access that information.

Hmm?

Yeah, but in general you cannot do:

def call(conn, opts) do
  a = 10
  throw :ack
end

try do
  call(conn, [])
catch
  v ->
    IO.inspect(binding(__STACKTRACE__)) # or other magic there
end

And get value of a. And that is what would be needed for what @mike_bianco want.

What a? There is no a in scope at the point binding is called? Is there supposed to be an a?

In debuggers for many languages it’s possible to “break on exception” where the debugger would attach immediately where an exception happened (not anywhere higher up the stack). This is similar to what Ruby’s pry-rescue does and this is what @mike_bianco wants.

I’m not sure if it’s doable on the BEAM but I’d love to see something like that (preferably using the :debugger instead of IEx but I know many people would prefer the pry)