Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple errors #17

Open
4 tasks
cognivore opened this issue Jun 27, 2023 · 0 comments
Open
4 tasks

Support multiple errors #17

cognivore opened this issue Jun 27, 2023 · 0 comments
Labels
good first issue Good for newcomers

Comments

@cognivore
Copy link
Contributor

cognivore commented Jun 27, 2023

Why?

errors =
  [cy, dy]
  |> Enum.filter(&Result.is_err?/1)

case errors do
  [] ->
    conn
    |> put_resp_header("X-Nonsense-Auth-Chal", cy |> extract)
    |> send_resp(200, dy |> extract |> Jason.encode!())

  _ ->
    conn
    |> send_resp(403, errors |> Jason.encode!() |> to(%Err{}))
end

This sucks, because the consumers may expect a well-formed Err of type

@type err(e_t) :: %{
        required(:__struct__) => Elixir.Uptight.Result.Err,
        required(:err) => %{
          required(:exception) => e_t,
          required(:stacktrace) => list(any()),
          required(:__struct__) => Elixir.Uptight.Trace
        }
      }

But instead they gets something of type %{ ... required(:err) => list(err(any())}.

How?

  • Create a new wrapper type Errs, which wraps such list
  • Define all the instances for it (can we derive them from a list?!)
  • Replace Applicative call to to(%Errs{}).
  • Demo handling Errs as well as Err from typescript.
@cognivore cognivore added the good first issue Good for newcomers label Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant