Is it possible to get more context information when anonymous function doesn't match

When a function doesn’t match, for example:

    |> Multi.update(:add_something, fn %{required: obj} ->
        ...
        end)

If this is called when required is not in the multi (but can be anything like, Enum.map([1, 2, 3], fn {} -> 0 end)) I get an error like this:

     ** (FunctionClauseError) no function clause matching in anonymous fn/1 in Book.CMS.Queries.multi_ensure_list/4

     The following arguments were given to anonymous fn/1 in Book.CMS.Queries.multi_ensure_list/4:

         # 1
         ... ctx

     code: CMS.update_page_children(site.id, page_r.gid, [
     stacktrace:
       (book 0.1.0) anonymous fn/1 in Book.CMS.Queries.multi_ensure_list/4
       (ecto 3.11.2) lib/ecto/multi.ex:973: anonymous fn/5 in Ecto.Multi.operation_fun/2
       (ecto 3.11.2) lib/ecto/multi.ex:883: Ecto.Multi.apply_operation/5
       (elixir 1.17.2) lib/enum.ex:2531: Enum."-reduce/3-lists^foldl/2-0-"/3
       (ecto 3.11.2) lib/ecto/multi.ex:856: anonymous fn/5 in Ecto.Multi.apply_operations/5
       (ecto_sql 3.11.2) lib/ecto/adapters/sql.ex:1358: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
       (db_connection 2.6.0) lib/db_connection.ex:1710: DBConnection.run_transaction/4
       (ecto 3.11.2) lib/ecto/repo/transaction.ex:18: Ecto.Repo.Transaction.transaction/4
       (book 0.1.0) lib/ecto/helpers.ex:56: Book.Ecto.Helpers.transaction/2
       test/book/cms_test.exs:98: (test)

My problem is with this line:

       (book 0.1.0) anonymous fn/1 in Book.CMS.Queries.multi_ensure_list/4

Because it is an anonymous function, there is no line number. Only thing I know is that the error was in multi_ensure_list which has like 4-5 anonymous functions like this. So it makes it hard to pinpoint.

Is there a way to improve this (only required for debugging, so I don’t care about a performance hit)?

Line number would be a start. But something like this would even be better:

95:    |> Multi.update(:add_something, fn %{required: obj} ->
                                       ^^^^^^^^^^^^^^^^^ arguments didn't match definition

I don’t think the stack traces can be improved super quickly but in the meantime you can just insert |> dbg() before the pipe stage that you feel might be failing?

1 Like