Hi Jeremy, I really appreciate all the materials you have shared. I could understand that wrapping errors with informative messages is one of important best practice treating errors. I'll keep it mind that :)
It was also very helpful to read errors section in Effective Go which you have shared. https://go.dev/doc/effective_go#errors Thank you. 2025년 2월 4일 화요일 오전 10시 40분 49초 UTC+9에 Jeremy French님이 작성: > 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/5f5f944a-1f8e-4f7e-8af6-3241409e6c91n%40googlegroups.com.
