I don't know if it qualifies as "best practice" but I think it would certainly qualify as convention to put the error as the last returned value. It is also extremely common to name the error "err", though that would have little impact on API consumers as they can rename it whatever they want.
It's also quite common at this point to wrap your errors with fmt.Errorf(), which allows errors.Is() to match the root error, or anywhere up the error chain, which can be convenient for your consumers. But I think I would dare to say that it's best practice to only wrap an error if you have something meaningful to add to it. For example "no such file or directory" is less helpful than "config: no such file or directory." but "can't find file: no such file or directory" doesn't add anything. I would also say that it's (somewhat) considered best practice to keep your errors terse and written for the developers, rather than flowery descriptive text written for the end user. If you need text for the end user, translate it at the point of intercepting the error and doing something with it. And of course, I believe Effective Go <https://go.dev/doc/effective_go> has a bit to say on the subject. On Monday, February 3, 2025 at 6:01:59 AM UTC-5 Byungjun You wrote: > In Java, checked exceptions allow developers to define in advance which > exceptions a function can throw. However, it seems that Go does not have > such a feature. Would it be considered a best practice in Go to document > the possible errors that an API function can return? Additionally, what are > some best practices that API providers can follow to help API users handle > errors effectively? > -- 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/dd1c04a5-1f16-4708-9b63-8b73cd9f2779n%40googlegroups.com.
