Hacker News Reader

Comment by masklinn | Hacker News Reader

1. That is a global static relationship rather than a local one dynamic one, which is the sense in which Go users use wrapping.

2. Idiomatic go type erases errors, so you're converting from `error` to `error`, hence type-directed conversions are not even remotely an option.

View on HN

`map_err` does not need to be type-directed; you can use an arbitrary function or closure. An enum variant can be used as a function mapping from the variant type to the error type, but we can do any arbitrary transformation:

    .map_err(|e| format!("Failed to read file: {e}")?;

But the "idiomatic Go" way of doing things sounds a lot closer to anyhow in Rust, which provides convenience utilities for dealing with type-erased errors:

    use anyhow::{Result, Context};

    fn foo() -> Result<()> {
        let data = std::fs::read("/some/file").context("Failed to read file")?;
        // ...
    }

Yes, I know that, but the argument (which, again, I called dubious) is that in both cases it's much easier to do just e.g.

  fn foo() -> Result<()> {
      let data = std::fs::read("/some/file")?;
      // ...
  }

whereas the current morass of Go's error handling means adding wrapping is not much more of a hassle.

But of course even if you accept that assertion you can just design your version of `?` such that wrapping is easier / not wrapping is harder (as it's still something you want) e.g. make it `?"value"` and `?nil` instead of `?`, or something.

> That is a global static relationship rather than a local one dynamic one, which is the sense in which Go users use wrapping.

In practice, the error type will be defined quite close to where the conversion is applied, so the static nature of it doesn’t feel too big.

Reply on news.ycombinator.com