3 ms·
> Uh? If you use `%w` in fmt.Errorf(), it should still work with .Is and .As? You still need a stable error to compare against in errors.Is. fmt.Errorf is not
by pkd 3y ago
> Uh? If you use `%w` in fmt.Errorf(), it should still work with .Is and .As?
You still need a stable error to compare against in errors.Is. fmt.Errorf is not going to provide that if the message is dynamic - which is almost always.
- throwaway894345 3y agoI think what you're talking about with "stable" and "dynamic" are error constants (like `io.EOF`) and instances of error types (like `url.Error` https://pkg.go.dev/net/url#Error https://pkg.go.dev/net/url#Error). You use `Is` for the former and `As` for the latter; fmt.Errorf's %w directive doesn't inhibit either case.
- simiones 3y agoThe problem is that the first-level error in most Go functions is fmt.Errorf(some error message, some args). The idea of pre-allocating an exported global error object (like io.EOF) is very rarely useful, and error structs are very rarely used either, because they require much more ceremony than just returning a fmt.Errorf() (or even an errors.New()) on the spot. But errors.Is is only useful if you take the first option, and errors.As is only useful if you take the second option. So, in practice, neither errors.Is nor errors.As are terribly useful, and %w just gives you a false sense of usefulness.
- throwaway894345 3y agoThis isn’t my experience. Most popular libraries seem to give an error type or value at least when someone might reasonably want to match on it. But yeah, if your coworkers don’t do this then Go can’t stop them (and in any case, I don’t see how fmt.Errorf() is to blame).