4 ms·
Error(error) -> Error(error) has strong if err != nil { return err; } vibes, and I don't consider that a good thing.
by thijsvandien 1y ago
Error(error) -> Error(error) has strong if err != nil { return err; } vibes, and I don't consider that a good thing.
- Alupis 1y agoThis is a trivial snippet. Often you will transform/map your error into another type (or deal with it in some way), so it's not so much `if err != nil { return err; }` vibes like you're thinking here. The beauty here is being compelled to handle both the happy and sad paths. You cannot just pretend the sad path doesn't exist.
- samdoesnothing 1y agoGood Go code also wraps errors...
- wavemode 1y agoIt's not just about wrapping. use-expressions, result.try and result.map eliminate the boilerplate of checking for errors entirely: https://erikarow.land/notes/using-use-gleam https://erikarow.land/notes/using-use-gleam
- samdoesnothing 1y agoOne man's boilerplate is another man's explicitness.
- debugnik 1y agoThat's what Gleam's use expressions[1] are for (the last example is exactly this case). Most languages with the same heritage as Gleam have grown a similar syntactical feature, such as OCaml's binding operators or F#'s computation expressions. Although I appreciate how simple Gleam's is while having similar power. [1]: https://gleam.run/news/v0.25-introducing-use-expressions/ https://gleam.run/news/v0.25-introducing-use-expressions/
- bmacho 1y agoNo, it doesn't have strong if err != nil { return err; } vibes. Pattern matching on Ok/Error is one of the best known error handling, while go error handling is one of the worst. They are about as far from each other as possible.
- smithcoin 1y agoInteresting, I find myself thinking the exact opposite.