> 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 of "accept interfaces but return concrete types" On Friday, 14 February 2025 at 13:29:35 UTC Axel Wagner wrote: > 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.NewReader` (and similar functions) returns a concrete type. > > This makes it the only case where it is kind of important to stay > consistent, because you can not get static checking and *have* to rely on > type-assertions if you want to figure out whether you got a specific > concrete type. > > > On Fri, 14 Feb 2025 at 14:24, Axel Wagner <axel.wa...@googlemail.com> > wrote: > >> On Fri, 14 Feb 2025 at 14:05, Jason E. Aten <j.e....@gmail.com> 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 >> <https://github.com/golang/go/commit/e4ae30f5f55b6b6ba2cb9a0c0e3b11d42dc162ee>, >> >> the errors package at least returned pointers. That was shortly after the >> `error` interface was introduced and even before that existed, package like >> `os` used pointer receivers for their error types. >> So, from what I can tell, at least, error types have always been designed >> using pointer receivers. >> >> >>> I don't think there is a wide accepted best practice here. >>> >> >> I strongly disagree. The standard library exclusively returns pointer >> type (except in `package syscall` I believe). There are good, technical >> reasons to use pointer receivers. People should use pointer receivers. >> >> >>> There are >>> libraries like "errors" but to me wrapping errors is gratuitous >>> complexity that >>> only adds noise. That's not a general consensus; just one >>> practitioner's opinion. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/golang-nuts/b0d1a19c-8025-4c36-ad39-a3c0571de3c9n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/b0d1a19c-8025-4c36-ad39-a3c0571de3c9n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/a5b8466d-36c0-4e73-a5f8-e100341253e4n%40googlegroups.com.
