Hello! I’ve been super impressed with the community here on the forum. Thanks for the help everyone has provided thus far!
I just finished my first side project in Elixir and there are a couple of things I’m missing from ruby-land, and some minor annoyances I’ve run into. I’m guessing there are extensions or tweaks I can make to eliminate most of these. I’d appreciate any insight—thank you!
Here’s the list of questions & missing tooling I’ve run into:
Automatically open up a REPL when an exception is thrown. In ruby, this is done via pry-rescue. Super helpful for quickly diving into the exact context where the error occurs.
In Phoenix, it would be amazing if the debugging plug (which displays a page when an exception is thrown) displays the variables bound in a specific scope so I can reproduce & fix errors quickly. (It would be even better if a REPL could be opened and interacted with on the exception page. better-errors does this in ruby.)
iex -S mix phx.server feels weird. It would feel a bit nicer if there was a mix phx.console which setup IEx for you.
Allow? [Yn] is really annoying when I’m debugging a piece of code. It would be great if you could auto-accept require IEx; IEx.pry requests.
In a debugging session, I couldn’t figure out how to navigate up and down the call stack. Is there something like pry-nav available?
Scan dependencies for security issues. In ruby, this is done via bundler-audit.
I couldn’t find a VS Code extension with phoenix* snippets. Is there a way to autogenerate snippets automatically from installed hex packages?
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.
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.
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)
Offtopic: This quote made my day, thank you so much! I am to use it to point out any architecture/design/performance/database/younameit issue from now on. Like in CR, when there is, say, an if on function argument instead of different pattern matching function clauses:
Is there supposed to be an a?
And even in the real life, talking to my wife; it is applicable literally everywhere.
It should present value of a form the place where exception was thrown. AFAIK it is not possible at all in Erlang, but this is how better-errors does it - it allows you to check values of local variables in place where exception was raised.
Ah, not sure I’ve ever used a language like that outside of stackless python. In C++/OCaml/Rust/Etc… once the stack frame is unwound anything that was existing before is now gone (although with some unsafe pointing munging you can sometimes get some old values, but don’t rely on that at all).
I’m not even sure how that is safe to do without heap-based frames. I’m guessing Ruby uses heap-based frames. The BEAM’s actors use stack-based frames so it is not safe to do such a mapping.
Except on the BEAM by the time the exception is unwound that stack frame is already gone and potentially even GC’d.
Except that stack frame is gone. If you want bindings from the thrown site then they need to be packaged up into the exception itself, which binding() would be great to use for, maybe make a library that has a dthrow/draise for a decorated throw and raise along with a dtry for a decorated exception handler for them?
What’s better-errors? Link please? I’m quite curious. ^.^
Those debuggers specifically overwrite the exception thrower with their own code (python adds a trace handler to the call, python’s debugging is actually very similar to the beam’s but at a far more fine-grained level) so as to be able to debug at the point of throwing instead of in the handler. Once you have unwound to the handler though, the information is gone.
Not necessarily, rather a library to decorate the throw/raise/try calls with extra information, though you’d have to remember to use it in each file when necessary.
That is why I am saying that such library cannot exist in Elixir world, as there is just not enough data
It is library for Rails that provide better error pages on Rails exceptions in development.
And it still would provide less informations as it would not handle errors in dependencies. Also you cannot overwrite try in Elixir at all (it is special form).
