How do you keep your software maintainable?

[desert bloom]

I'm working through the Gleam Language Tour. I decided to revisit some of the concepts, especially the results-module and especially the use keyword

https://tour.gleam.run/standard-library/result-module/
https://tour.gleam.run/advanced-features/use/

It keeps the callbacks and error checking under control, but it seems like you lose a lot of information along the way. For example, how would we know which function returned an error? I was also surprised that the int.parse example returned an Error(Nil) with no extra information.

There must be a trick I'm missing. What are you guys doing to ease the burden of maintenance?

Also, I found the page on Option module a little confusing. Is it discouraged to use Option in Gleam since Result is heavily favored in the language? Should we avoid it in normal Gleam code?

[sterile pine]

For handling errors generally the pattern is to set the value in the error to have as much detail as you want/need. So I'm practice, Rather than returning Error(Nil) you would likely create a custom record with all the different error cases you want to return and make sure your function returns that (depending on the specific code you might need to use different functions than just result.try as shown in the tour)

[rare violet]

one approach i use is:

  use rows <- try(
    int.parse(input)
    |> result.replace_error(InvalidRows(input)),
  )

[sterile pine]

For the second question about option, it's not that Option is discouraged but rather that Result and Option have different intentions. Result is for things that may succeed or fail where as Option is more of like an optional field that may or may not exist. Option is generally more common in structures than functions but it depends

[desert bloom]

@rare violet that is pretty cool. It's like a streamlined version of if err != nil error wrapping in Go. Thanks for that.

@sterile pine, they do mention that aspect about Option in the tour, but I'm focusing more on this statement:

Some languages have functions return an option when there is no extra error detail to give, but Gleam always uses result. This makes all fallible functions consistent and removes any boilerplate that would be required when mixing functions that use each type.

[sterile pine]

"always" in this case is in the context of functions that return data. Since functions are generally chained together and can have failure conditions it's usually easier/less work to return Results and map accordingly. 1 way to think of it is that Options work well for inputs/structures where it is guaranteed the things either exists or doesn't. Results work well with function outputs

[desert bloom]

Thanks, that does clarify it a bit more. But in order to use Options as inputs, we'll need another sort of shim to get it to flow well with functions that return Results?