make errors when piping in expressions safer #14795

zachdaniel · 2025-09-27T14:36:46Z

For example:

If you pasted this into an iex shell, you might have a very very bad day.

MyApp.Accounts.User
|> Ecto.Query.where(user], user.id == 1) # note the missing open bracket
|> MyApp.Repo.delete_all()

This is still rough, things I'm not sure about:

I'm not sure how we feel about the method of just rewriting the evaluated code to check for this condition.
I'm trying to display the operator, but it's using the tokenized representation of it and I couldn't find a mapper for that. I can just not display the operator, or I can write a mapping function myself.
I should probably colorize and indent the message properly, but wanted to validate the approach before pushing further.

In practice it looks like this:

Interactive Elixir (1.20.0-dev) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> 1
1
iex(2)> |> Kernel.+-(1)
** (ArgumentError) cannot pipe v(-1) into Kernel.+() - 1, the :- operator can only take one argument
    (elixir 1.20.0-dev) lib/macro.ex:341: Macro.pipe/3
    (stdlib 7.0.2) lists.erl:2466: :lists.foldl/3
    (elixir 1.20.0-dev) expanding macro: Kernel.|>/2
    iex:2: (file)
iex(2)> |> Kernel.+(1)
Skippping evaluation of:

|> Kernel.+(1)

For safety, you cannot begin an expression with `arrow_op` when the last expression was an error.
iex(3)>

CleanShot.2025-09-27.at.10.31.14.mp4

For example: If you pasted this into an iex shell, you might have a very very bad day. ```elixir MyApp.Accounts.User |> Ecto.Query.where(user], user.id == 1) # note the missing open bracket |> MyApp.Repo.delete_all() ```

lib/iex/lib/iex/evaluator.ex

josevalim · 2025-09-27T14:49:50Z

Looks promising! I think you can simplify things a bit. I don't think we need, for example, to repeat the expression, it should be clear it is the one right above.

Co-authored-by: José Valim <[email protected]>

lib/iex/lib/iex/evaluator.ex

to handle syntax errors, send to the evaluator to set `iex_error` to `:force` if its set to `:force`, we downgrate it to `true` first.

zachdaniel · 2025-09-27T15:30:15Z

Okay, I've done some cleanup. I realized we weren't handling syntax errors (i.e errors not coming from evaluating the code) and I had to do something a bit hacky to make that work.

I send code to the evaluator to Process.put(:iex_error, :force). It is using :force, because if it just set true, the evaluator would immediately delete it after successfully evaluating it. This way if it's set to :force, the evaluator sees that and sets it to true. I'm not a fan of this but it was the quickest path to "a" solution.

Ready for another look given the simplification and the parse error handling concept.

lib/iex/lib/iex/server.ex

josevalim · 2025-09-27T16:45:32Z

One last comment to clean up the interfaces. Do you think we could have some tests? Perhaps in interaction_test.exs?

zachdaniel · 2025-09-27T16:46:46Z

Yep, will wrap up and add tests later today or tomorrow 👌

zachdaniel · 2025-09-27T21:36:50Z

Tests added 👍

lib/iex/lib/iex/evaluator.ex

josevalim · 2025-09-28T14:09:44Z

Beautifully done. Will be merged once CI passes!

josevalim · 2025-09-28T14:18:11Z

💚 💙 💜 💛 ❤️

make errors when piping in expressions safer

834d77b

For example: If you pasted this into an iex shell, you might have a very very bad day. ```elixir MyApp.Accounts.User |> Ecto.Query.where(user], user.id == 1) # note the missing open bracket |> MyApp.Repo.delete_all() ```