6 Comments

What about the case when func you are calling is hidden behind an interface?

Example:

```

func read(r io.Reader) error {

_, _ := r.Read(x) // here we dont realy know what function we are calling

}

read()

```

I think the opposite approach is more suitable: function should always put information about himself into the error message.

Like this: fmt.Errorf("pkg.fn: %w", err)

Also it's how standart library doing it.

Expand full comment

While I agree with your approach on a philosophical level, it goes against the established practices of the Go standard library (and community libraries in the style of the Go standard library). It turns out that the opposite approach — “don't repeat information that was supplied to the callee that produced the error” — seems to be equally coherent if applied consistently.

(In my experience the idiomatic Go approach does require more unwrapping and repacking of errors to avoid redundancy, but it at least avoids an impedance mismatch between user APIs and the standard library.)

Expand full comment