Re: [go-nuts] Using errors.As error-prone

Ah. Yes, of course. Pointers always. I was trying to suggest that creating your own error structs in the first place opens a needless Pandora's box. It is just extra trouble that is trivially avoided if you simply think of errors as strings, and create them only with fmt.Errorf(). Certainly the

Re: [go-nuts] Using errors.As error-prone

> On Fri, 14 Feb 2025 at 14:24, Axel Wagner > wrote: > >> On Fri, 14 Feb 2025 at 14:05, Jason E. Aten wrote: >> >>> I myself still use the classic string based-errors as >>> original designed. >>> >> >> I'm not sure what you mean here. >> > I'm sorry to be confusing. I'm not doing anything tricky

Re: [go-nuts] Using errors.As error-prone

> That is, functions never return `*os.PathError` or the like ... which of course is a good thing, as nil pointers and nil interfaces are different. This is something that confused me when I first came to Go: https://go.dev/play/p/R-oZwlqimA2 Hence errors are the exception to the general rule o

[go-nuts] Deletion of x/tools/refactor/rename + ... (#69538)

In issue https://github.com/golang/go/issues/69538 I propose to carve out submodules for the following obsolete packages, then tag and delete them: - golang.org/x/tools/refactor/rename - golang.org/x/tools/refactor/importgraph - golang.org/x/tools/go/buildutil - golang.org/x/tools/cmd/gomvpkg App

Re: [go-nuts] Using errors.As error-prone

On Fri, 14 Feb 2025 at 14:24, Axel Wagner wrote: On Fri, 14 Feb 2025 at 14:05, Jason E. Aten wrote: I myself still use the classic string based-errors as original designed. I'm not sure what you mean here. I'm sorry I confused you. I'm not doing anything tricky or sophisticated at all. I

Re: [go-nuts] Using errors.As error-prone

I'll note that `error` is a special case, as it's an interface type that is almost never mentioned via it's implementation, statically. That is, functions never return `*os.PathError` or the like, but they always use `error` as a return type, which is different from `io.Reader`, where e.g. `strings

Re: [go-nuts] Using errors.As error-prone

On Fri, 14 Feb 2025 at 14:05, Jason E. Aten wrote: > I myself still use the classic string based-errors as > original designed. > I'm not sure what you mean here. From its first commit , the errors package at least ret

Re: [go-nuts] Using errors.As error-prone

I myself still use the classic string based-errors as original designed. These are immutable values that are easy to compare with == and search with strings.Contains(). I don't think there is a wide accepted best practice here. There are libraries like "errors" but to me wrapping errors is grat

Re: [go-nuts] Using errors.As error-prone

> The best practice is pointer errors. If that is an accepted best practice, wouldn't it make sense to have a go vet or linter check that verifies that (at least for public error types)? It is really not visible from the api and developers will only start thinking about it once they have been bi