Help an Elixir beginner find missing development tooling!

[OvermindDL1]

@hauleth

It is library for Rails that provide better error pages on Rails exceptions in development.

Ah, never used Rails or Ruby, only better_errors library I’d heard of was for OCaml. ^.^;

@hauleth

And it still would provide less informations as it would not handle errors in dependencies.

Well you could but you’d have to apply a preprocessor to the files before feeding them into the compiler, doable but would require a mix.exs line added and a lot of work in the library.

@hauleth

Also you cannot overwrite try in Elixir at all (it is special form).

But a macro that processes the entire module can modify it.

[mike_bianco]

But a macro that processes the entire module can modify it.

Would it be possible to write a macro which processes every module loaded to override try to include this debugging information?

I still find this one of the most parts of ruby I miss once. For instance, if I’m running a test and it’s failing due to a function deep in the stack I would love to know what arguments were passed to that function so I can quickly debug what might be happening higher in the stack.

In ruby, I can just inspect the args and quickly modify the code. In elixir I have to add pry to the right place in the stack that I control, rerun the tests, and hope that I placed the debugger in the correct spot.

I think adding this feature to elixir (in dev/test mode only) would be amazing and be an incredible help to users.

[hauleth]

@mike_bianco

I would love to know what arguments were passed to that function so I can quickly debug what might be happening higher in the stack.

Just use erlang:trace/3 or dbg. Due to the nature of Erlang the frame of the failed code do not exists anymore, so you cannot get any more information that is showed by the VM, you need to fall back to other features - tracing is one of them. This can be shown for example in form of:

Task.async(fn -> 1 + :a end)

It has no information from where it was called at all, so you will have no information where the error came from other than it come from the new process.

[mike_bianco]

@hauleth Where can I find more information about using trace/dbg? How can I can debug a piece of code I don’t own (pulled in by mix deps)? Thanks!

[hauleth]

In the Erlang docs. Yes, you can trace (almost) all Erlang function calls (some BIFs aren’t traceable for performance reasons, but there is only few of them).