`map_err` does not need to be type-directed; you can use an arbitrary function or closure. An enum v...

NobodyNada • last Tuesday at 7:34 PM • 1 reply • 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")?;
        // ...
    }

Replies

masklinn • last Tuesday at 7:56 PM

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.

alt Hacker News

Replies