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

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

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

It's also consistent with the common idiom of errors.New("foo") which returns a pointer (to an unexported type) - although this doesn't appear to be documented, except that "Each call to New returns a distinct error value even if the text is identical" On Wednesday, 12 February 2025 at 09:06:08

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

On Wed, 12 Feb 2025 at 09:21, cpu...@gmail.com wrote: > I've had some ongoing confusion about using errors.As (see > https://play.golang.com/p/m4_cXCzOViD). The issue I'm having is this part > of the contract: > > > An error matches target if the error's concrete value is assignable to > the valu

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

I've had some ongoing confusion about using errors.As (see https://play.golang.com/p/m4_cXCzOViD). The issue I'm having is this part of the contract: > An error matches target if the error's concrete value is assignable to the value pointed to by target I always expected (yes, I know), that ba