sb logoToday I Learned

4 posts by bryannaegele

Moar backtrace!

If you’re dealing in logs and an exception is thrown in Elixir, sometimes the backtrace is entirely unhelpful, like this.

(jason 1.2.2) lib/jason.ex:199: Jason.encode_to_iodata!/2
(postgrex 0.15.9) lib/postgrex/type_module.ex:897: Postgrex.DefaultTypes.encode_params/3
(postgrex 0.15.9) lib/postgrex/query.ex:75: DBConnection.Query.Postgrex.Query.encode/3
(db_connection 2.4.0) lib/db_connection.ex:1205: DBConnection.encode/5
(db_connection 2.4.0) lib/db_connection.ex:1305: DBConnection.run_prepare_execute/5
(db_connection 2.4.0) lib/db_connection.ex:574: DBConnection.parsed_prepare_execute/5
(db_connection 2.4.0) lib/db_connection.ex:566: DBConnection.prepare_execute/4
(postgrex 0.15.9) lib/postgrex.ex:251: Postgrex.query/4

Where did this exception actually happen?

Turns out the default depth is only 8 calls deep! The good news is it’s configurable.

:erlang.system_flag(:backtrace_depth, new_depth)

Bump that up to 20 or 30 and you’ll probably find the real culprit 😎

Compiler warnings as errors at test time

We use mix compile --warnings-as-errors in our CI linting step to catch potential issues before they hit production. This is great but it’s a command I never run prior to pushing up a pull request, so sometimes they slip through and I have to do a fixup and push again. Wouldn’t it be great if these could be caught when you ran your test suite to catch them prior to PR?

Johanna Larsson (@joladev) had a great solution! Add this to your test_helper.exs file and you can surface these at test time.

# test_helper.exs
Code.put_compiler_option(:warnings_as_errors, true)