Result to Response

[wwall3r]

Hi! I'm working on a small project to try out Gleam in a larger sense (coming from functional in Elixir but have also done a small amount of Rust). I've been working on better error handling. I've adopted snag, which helped a lot with not needing boilerplate error types at each level of the codebase.

This is a web project, and so most of the things I do (access a database, load a file, hit a remote service) have a Result type. Using the use thing <- result.try(...) syntax is quite nice as long as your return value is still a Result. However, at some point, that result has to become a Response. Initially I had nested case statements, but of course that degrades quickly if you have more than 2 things you need to do. I liked the notion from Go, where the error is always handled next to the call like so:

thing, err := doThing()
if err != nil {
  // format error response and return
}

I ended up making the following helper function, which is similar to result.try, but has a function for mapping the error into the expected type:

pub fn try_and_map_error(
  result: Result(a, b),
  map_error: fn(b) -> c,
  next: fn(a) -> c,
) {
  case result {
    Ok(value) -> next(value)
    Error(err) -> map_error(err)
  }
}

I didn't see anything like that in the stdlib but maybe I'm not on the same page with whatever it is named. In functions which produce responses, that lets me use it like so:

pub fn handle_form_submit(ctx, req) {
  use thing1 <- try_and_map_error(
    do_thing1(ctx),
    fn(snag) {
      // format http error response
    },
  )

  use thing2 <- try_and_map_error(
    do_thing2(ctx, thing1),
    fn(snag) {
      // format http error response
    },
  )

  // format success response
}

Is there a way of doing this in the stdlib which I am missing? Or am I way off and another pattern would be better?

[lpil]

I would recommend not converting to a response early and keep it all one result type until the end. This removes this issue and also keeps a good separation of concerns between domain logic and the HTTP representation.

I would also likely avoid snag in this area as it holds little information that can be used to build HTTP responses. I suspect this info-sparse error type may have been what pushed you towards making the response early.

Check out the Wisp guides, they show a recommended pattern for error handling.

[wwall3r]

I don't believe this is early (it's possible you meant "early" as in "early return" but I took it as "early in the request processing"), as it is the handler for the route. e.g.

case method, path {
  POST, ["form"] -> handle_form_submit(ctx, req)
  // ...
}

Every level beneath handle_form_submit() uses result.try and keeps everything as a Result.

I did have a look at the Wisp examples, and while helpful for the overall topic they were covering, I found the error handling to be too simplistic for real-world use. Even in the case of a JSON API, I would want to return error codes or messages saying why something failed so that the consumer of the API can would have better instructions on how to proceed. This is fine as the examples are more focused on the topic they are trying to show off. Perhaps a more robust error-handling-specific example might be helpful?

In my case, the snag error isn't being sent to the user, it's being used for logging and adding the error to open telemetry so that I can get the full context if something goes wrong. Effectively, what I'd want to see when digging into an issue is a layer of "error submitting form -> root cause like DB constraint violation or decode failure." What I would want to send to the user is more like "this username is not available," or "token has expired," or some other instruction on moving forward.

Additionally, I'm doing a server rendered application, so even though the snippets are generally small, I do need to format the error as HTML that is visible to the user and display it.

[lpil]

It's not too simple a pattern! I have used this pattern professionally for many years and it works well. In some languages such as Rust it is overwhelmingly the norm.

You should use this pattern, it will solve this problem and result in better separation of concerns and the ability to test this domain code easily.

[wwall3r]

Based on my understanding, it would require me to come up with an error type with a variant for every error that could occur in the application, and somehow store/stringify/format the original underlying error from whatever module or library, map the original error to the new one, and then match on that error type at the end of the function to produce the HTML response. No? That's not necessarily bad. I've seen that used in several projects. However, if I start having to spend more time on error handling than on my application, I think we've probably lost the thread unless we have life-or-death mission-critical requirements.

That seems like an unnecessary intermediate step when the point of the function is to produce an HTML response. I can already test the underlying doThing() functions separately via unit tests (they have their own modules/etc). I can already also test this function via integration tests (it outputs an HTML Response either way so I'm not sure how a change in its inner structure affects testing it). Secondly, using a match at the end of the function separates the error handling from the call, which I would consider a bad thing because it is less likely to get adjusted along with the call (e.g. call is removed and can no longer produce the error, but did not remove the error from the error type or the associated match/matches).

I appreciate you discussing it. Really enjoying the language!

[GearsDatapacks]

That's the way to do it. In a statically typed language like Gleam, that gives your code a much better understanding of what went wrong than a simple String does.
You won't spend a huge amount of time writing error handling code; it's super easy to add a new variant to your error type (even easier with the upcoming code action in 1.11!), and converting the error to an HTTP response after that should only be a few lines as well.
The more you use it, the more you get used to it and the less friction it causes in your application.

[lpil]

Yup. That's how errors worth in statically typed languages, and it's also considered best practice in many dynamic languages such as Python.

Modelling your errors is a very useful thing to do when designing an application.